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ABSTRACT 



This thesis is designed to propose the need for database establishment at the 
Army division level to improve the efficiency and effectiveness of the defense resource 
management system (DRMS). Since the DRMS requires complex and multi-faceted 
activities which includes financial, material, and facility data, the application of 
accurate and timely data is a crucial component. A limitation of the current resource 
management system is that it does not effectively satisfy the user's information 
requirements. A relational database system can facilitate to solve these problems by 
the report generator capability or ad hoc queries in a simple SQL query operation. 
Considering the current situation of the ROK Army division equipped with the 
computer mainframe, the initiation of this study can provide the ROK Army 
authorities or the computer experts with a motivation to develop the database system 
as the primary means of reinforcing the DRMS. 
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I. INTRODUCTION 



Korean military spending is reaching one third of the total government budget 
and 6% of GNP. In spite of this high proportion, the goal of self defense has not been 
accomplished. As a means of obtaining defense capability to balance military power 
between ROK and North Korea, greater efficiency and effectiveness in the use of 
defense expenditures is required. 

It was not so long ago that the Korean Army paid attention to resource 
management. Even though we have run through a series of trial and error m the 
resource management system, we could not establish a well-developed system for 
controlling operational data and for measuring performance in terms of cost 
effectiveness analysis. Furthermore, the absence of reliable data about operating 
activities made it difficult to analyze and evaluate possible improvements. 

A. THESIS OBJECTIVE 

This thesis examines the current ROKA defense resource management system 
(DRMS) and proposes an DRMS database design at the division level to improve its 
efficiency and effectiveness. 

Since the resource management system deals with very complex and multifaceted 
financial, material, and facility activities, the availability of accurate and timely data is 
a crucial factor in the successful allocation and expenditure of limited resources. 

This thesis is developed around the following questions: 

1. What is the current resource management system of ROKA? 

2. What are the information requirements for the effective resource management? 

3. How can a relational database management system support the resource 
management in the division level? 

4. How can data manipulation of the relational model meet the diverse 
information requirements? 

5. What capabilities exist for expenditure analysis and performance evaluation in 
this database environment? 

The overall objective of the thesis is to propose a course of action to improve 
ROKA resource management system from the user's point of view, and to show the 
possible application of the relational model database in the data analysis. 
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B. THESIS ORGANIZATION 



The thesis consists of 6 main chapters. Chapter II provides the overview of the 
current ROKA resource management system. Limitations as well as the status quo will 
be surveyed as the starting point of this thesis. 

Clear identification of the information requirement is the fundamental matter for 
any database approach. In Chapter III, the user's needs are examined. The 
identification of required output data will provide the motivation for the database 
design. 

Chapter IV introduces the principal concepts of the data management approach 
from the user's viewpoint. The main topics are: what is the database?; why do we need 
a database?; how is it operated? 

The main research of the thesis will be performed in Chapters V and VI. In 
Chapter V, the actual transaction or activities of the resource management system are 
represented as tables to be manipulated in a relational database management system. 
(The relational model is widely accepted as a powerful and flexible database technique.) 
Examples are provided to show how to derive the required information by using the 
SQL data manipulation language. Chapter VI describes various analyses of the 
resource management expenditures which can be derived from this database. We will 
demonstrate the analysis with appropriate models in three cases. 

Finally, based on the preceding research, we conclude the theses by proposing a 
course of actions to implement an effective and efficient resource management system 
in ROKA division level. 

C. THESIS SCOPE 

Throughout the thesis, the detailed technical issues on information systems and 
database design will not be covered, rather we focus on the application capability of 
the output data in the relational model. Since the urgent requirement for the ROKA 
in coping with the resource management is the availablity of the timely and accurate 
operational data, our main concern is a well-developed database system as the key 
element of the resource management information system. 
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II. REVIEWS OF REPUBLIC OF KOREA (ROK) DEFENSE RESOURCE 

MANAGEMENT SYSTEM 



A. GENERAL 

In order to provide funding for an increase in capital investment, in July 1983, 
Republic of Korea (ROK) President Chun issued an executive order requiring the 
Korean armed forces to reduce the operating expenditure in the nation's defense 
budget [Ref. 1: p. 3]. The objective of this order was to take initial steps toward 
improving defense resource management. 

While the ROK economy has made excellent progress, defense spending is 
reaching 6% of GNP or approximately one third of the government budget. This 
figure is considered high by free-world standards. Despite this high level of spending, 
the imbalance of military power between the two Koreas remains in favor of the North 
as shown Table 1 [Ref. 2: pp. 59-63). 

As a means of obtaining greater defense capabilities to balance military power 
between South and North, the Government of ROK has taken steps to obtain greater 
efficiency in its use of defense funding. Promoting the efficiency of defense operating 
expenditures will be the best way to accomplish the objective of self-defense. 

B. REVIEW OF THE REPUBLIC OF KOREA DEFENSE RESOURCE 

MANAGEMENT SYSTEM 

1. Background and History 

U.S. security assistance to the ROK has played an essential role in 
strengthening the military capabilities of the ROK. In the past, Korea's main focus of 
defense management was to obtain as many resources as possible. Government policy 
makers didn't feel the need for advanced management systems and specialists to 
enhance defense productivity. 

In the 1950s and 1960s, arms transfers from the U.S. were made under the 
Military Assistance Program (MAP); during the subsequent period of ROK Armed 
Forces Modernization Program (1971-1975), the military capabilities of ROK were 
greatly enhanced under such U.S. Military Aids Programs as MAP and the Military 
Assistance Service Fund (MASF). 

Since the mid-1970s, U.S. security assistance policy toward ROK has 
undergone a tremendous change. Assumption of increased responsibility Tor its own 
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TABLE 1 

COMPARISON OF MILITARY POWER BETWEEN SOUTH AND 

NORTH 


Contents 


ROK 


North Korea 


Rate 


* Man power 

- Regular 

- Reserve Forces 


622,000 

5,780,000 


785,000 

5,170,000 


1 : 1. 3 
1. 2 : 1 


* Equipment 

- Artillery 

- Tank 

- Armored Vehicle 

- Submarine 

- Destroyer 

- Naval Vessels 

- Bomber/Fighter 

- Transporter 

- Total Aircraft 


2,800 

1,200 

800 

20 

101 

450 

61 

618 


5,300 

3.200 

1.200 
21 

2 

537 
- 740 

369 
1,322 


1 : 1. 9 
1:2,7 
1 : 1.5 

1 : 5.3 

1 : 2. 1 


* Defense spendings 

- GNP( 19831 

- Defense Budget 

- Cumulative total 
Since 1970 


$ 75.3 B 
$ 4. 34B 

$ 28. 53B 


$ 14. 5 B 
5 3. 4 B 

$ 31.4 B 


5. 2 : 1 
1.3 : 1 

1 : 1. 1 



defense made ROK MOD realize the need for a better and more efficient allocation of 
defense resources. Toward this end, the U.S.'s Planning, Programming, and Budgeting 
System (PPBS) was studied and introduced. Finally, the Planning, Programming, 
Budgeting, Execution, and Evaluation System (PPBEES) unique to ROK military 
needs was developed as shown in Figure 2.1 [Ref. 3: p. 86]. 

The concept of PPBEES is to design a bridge between the planning and 
programming phases and to feed back the results of performance evaluations for use in 
subsequent phases of planning, programming, and budgeting. Under PPBEES, 
increments to programs were considered in the programming phase and these 
increments were then translated into line item entries for the traditional budget 
submission. [Ref. 4: p. 91] This PPBEES system aims to develop a sound Defense 
Resource Management System by adding the execution and evaluation phases to the 
previous budget system. 
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Figure 2. 1 The PPBEES System. 

On February 25, 1983, the Defense Budget Revolution Committee was 
established in order to make an intrinsic improvement in the defense budget system. 
Its main objective was to establish a rational cyclic process of planning, programming, 
budgeting, execution, evaluation. [Ref. 4: p. 7] The Budget Revolution Committee 
selected eight major functions to implement the PPBEES system. [Ref. 1: pp. 17-32] 
The eight major functions are: 
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• Decision-making process 

• Planning-programming process 

• Program management system 

• Decentralized management system 

• Analysis and evaluation system 

• Management information system 

• Resource management staff function 

• Reorganization 

These are explained in detail in the following section. 

2. Decision Making Process 

a. Basic Concept 

The process suggests that the national defense objectives be translated into 
budgetary decisions. After identifying alternatives necessary to carry out the mission, 
cost-effectiveness analysis for defense related programs are to be performed in order to 
determine the priority of alternatives within the given budget constraints. 

b. Directions toward Reform 

At the beginning stage, each project requires an analysis report to justify its 
budget request in detail; thus nonessential projects can be eliminated early. For the 
appropriate force-mix, first, we establish the strategy concept to meet the enemy's 
threat and then decide the resource allocation between each force (Army, Navy, Air 
Force, Homeland Reserve Forces). 

In the past, the Korean government had focused on the process of 
obtaining a budget, therefore, the execution and evaluation phases were not considered 
in detail. There was no consistency in the management cycle of planning- 
programming-budgeting. Because of the abstract nature of programming criteria, 
planning was not sound. Distribution of defense resources, therefore, was inefficient, 
and the productivity of the defense budget was very low. [Ref. 1; p. 17] 

3. Planning-Programming Process 
a. Basic Concept 

The concept of planning-programming process explains the process of 
budget organization. It is important to understand the roles of both long-range and 
short-term planning in the overall planning scheme. Requests for military forces to 
meet the strategic and force maintainance programming must be coincident. 
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b. Directions toward Reform 

By integrating the Strength Improvement Plan 1 and Defense Five-Year 
Program, 2 the investment budget and operating expenditure could be allocated 
properly. The adjust and control function of budget programming would be 
strengthened. 

Evaluation of projects can be performed more easily by using uniform 
documents in the planning, programming, and budgeting process as shown in Table 2. 
(Ref. 3: pp. 90-91] 

It is then possible to manage defense projects more effectively. Each 
expenditure criteria derived from comparing the performance result of user-level units 
can be used as guidance for planning and budget organization. [Ref. 1: p. 19] 

4. Program Management System 
a. Basic Concept 

Until now, weapon system procurement programs were performed by ROK 
MOD according to the Strength Improvement Program. However, the maintenance 
and supply support plans were performed by each service department, so, there were 
no responsibility centers for each stage. Korean military planners believe that each 
program must have consistency from beginning to end. Therefore, the weapon system 
selection phase, research and development, test and evaluation, production, quality 
assurance, procurement, deployment, and operation phases, all must have consistency. 
At the first stage, that program which has the highest priority is selected based on its 
level of investment or contribution to strength improvement (strengthening of war 
potential). Secondly, a project manager will be selected to improve the efficiency of 
program execution and management of weapon system organization and logistic 
support. The manager selected must be accountable and must be given the necessary 
authority to fulfill these responsibilities. 

^his plan started after the 8th session of the Korea-U.S. Ministerial Security 
Conference of August 1975. The principal ingredients of the plan are the increase of 
military hardware, the expansion of defense facilities and the development of the 
defense industry. At the begining stage, the primary fiscal sources were the national 
defense tax and U.S. financial support and other cooperation. Currently, the main 
source is the national defense tax. 

2 Based on the Strength Improvement Plan this program is aimed at securing a 
defense capability to repel north Korean Aggression unaided by China or Russia. This 
program called for the attainment of this goal within 5 years, starting from 1975. After 
the first 5- Year Program, however, every 5 years, new 5- Year Programs have been 
extended. 
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TABLE 2 




DOCUMENTS IN PLANNING-PROGRAMMING-BUDGETING CYCLE 


Month 


Year X-3 


Year X-2 


Year X-l 


JAN 

FEB 


Long Range Strategy 
and Policy 


National Strategic 
Objective Plan, 
Research and 
Development Plan 


Militarv Budget 
Requirements 


MAR 


Middle Range 
Intelligence 
Estimation 


Middle Range 
Defense Policy 


- 


APR - 


- 


5 Year Plan 
Guidance, 

Strength Improvement 
Guidance 


- 


MAY 


Strategic objective 
Guidance, 
Research and 
Development 
Guidance 


- 


Defense Budget 
Requirement, 
Service Improvement 
Executive Guidance 


JUN 

JULY 


- 


Service Strength 
Improvement 
Requirement 


Service Strength 
Improvement Plan 


AUG 


- 


Service 5 Year 
Requirement 


- 


SEPT 


Service Strategic 
Objective Plan, 
Service Research and 
Development Plan 


- 


- 


OCT 


- 


Strength 

Improvement Plan 


Defense Strength 
Improvement 
Execution plan 


NOV 


- 


Annual Defense 
Policy 


- 


DEC 


- 


- 


National Assembly 
Authorization and 
Appropriation 
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b. Directions toward Reform 

Project management requires approval of high authority at key decision 
points (milestones). Life cycle cost (LCC) is considered on an equal basis with system 
performance, schedule, and logistic supportability. A clear line of authority, 
responsibility, and accountability for the management of programs is established. 
Competition in contracting is also required. [Ref. 5: pp. 36-38] 

5. Decentralized Management System 

a. Basic Concept 

The unit commander has the responsibility for managing the unit's 
resources such as manpower, funds, materials, and facilities. Complete autonomy in 
spending on the part of the operational commander is emphasised. First, the 
commander will be motivated to control costs by establishing his ownership and 
responsibility to manage his unit efficiently. Secondly, each soldier will be motivated 
to find cheaper substitutes, because the remaining funds which result from efficient 
management could be used for the soldiers' welfare, such as recreation facilities, a 
library, sport equipment, etc. 

By developing a proper accounting report system, it is possible to estimate 
the performance of each unit and summarize aggregate totals. For example, 1/4 ton 
jeep operation can be divided into 3 categories according to the following purposes : 
commanding, operation, and administration. The maintenance cost per vehicle could be 
compared with that of the same purpose vehicle of other troops, but it is difficult to 
say that lower cost always means better performance. 

b. Directions toward Reform 

By strengthening the function of resource management, each unit 
commander can assess his unit's assets and make an analysis of the results of his 
resource spending, which can facilitate economic troop management. To establish the 
management information system, it is necessary to first develop a new accounting 
system that can integrate the total resources and adopt the user-centered logistic 
management which is based on decentralized principles. [Ref. 5: pp. 34-36] 

6. Analysis and Evaluation System 
a. Basic Concept 

This system was established to provide basic data needed in successive 
planning, programming, and budget compilations. The basic data can be derived from 
the result of comparative analysis between the required mission performance level and 
the results of resource spending. 
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b. Directions toward Reform 

The mission performance level and the result of resource spending could be 
analyzed and evaluated by developing a new accounting system and the establishment 
of a new auditing policy which is consistent with the concept of resource management. 
At the programming and budgeting stage, the previous data of expenditure analysis 
could be used to make programming decisions as well as budget formation based on 
performance criteria. 

7. Management Information System (Computer-Based) 

a. Basic Concept 

In order to operate the Defense Resource Management System efficiently, 
information (demand, procurement, operating-inventory control, performance 
evaluation...) must be provided at the right time and right place. This system must be 
computerized to obtain the benefits of speed and accuracy. This system also can assist 
in decision making for resource allocation. 

b. Directions toward Reform 

DBMS (Data Base Management System) was established to assist the 
process of analysis, evaluation and the accurate computation of resource demands. 
Constructing computer networks among MOD, each division of the Army, Naval 
theatre commands, and Air Force flying corps will facilitate this process. [Ref. 6: p. 13] 

Computerized inventory management of logistic materials and other major 
resources can facilitate the decentralization of the resource management system, which 
includes procurement, storage, and distribution procedures. Computerizing the 
process of 5 year programming, budget organization, and execution, can accomplish 
the objective of budget revolution in a short time. 

8. Resource Management Staff Function 

a. Basic Concept 

Strengthening the function of the resource management staff is intended to 
support the decentralized unit management system by properly giving incentives to the 
units according to their performance. 

b. Directions toward Reform 

Three separate functions (finance, logistics, and facility engineering) were 
integrated and the overall management staff controls all resources. The overall 
management staff is responsible for all resource management in the unit, and so seeks 
the most economic level of unit operation, prepares the unit's budget, and handles 
material accounting and fund accounting. (Ref. 1: p. 31] 
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9. Reorganization 

a. Basic Concept 

The newly designed Defense Resource Management System is based on the 
concept of PPBEES (planning, programming, budgeting, execution, evaluation system). 
Thus, a new organizational structure is needed to support the new procedure. This will 
require integration, restructuring and reinforcement of the new system to reorganize 
the current structure to meet the new task. 

b. Directions toward Reform 

The old structure must be reconized through changes based on an 
integrated logistic system. A part of the new organization must be a cost and program 
analysis function which should be accomplished through a special organization manned 
by professional personnel. [Ref. 1: p. 32] 

After introducing the Defense Resource Management System in 1983, ROK 
MOD has made a concreted effort to implement the system in the ROK military as 
follow's: 

• Selection of the sample units according to the type of troops. 

• Design of the common structure documents used in the programming and 
budgeting phases. 

• Implementation of the system in the experimental troops. 

• Evaluation of the performance results in the experimental troops. 

• Amendment and reinforcement in the intrinsic nature of Defense Resource 
Management System introduced. 

• Inspection of the execution of the system. 

Finally, from the beginning of 1986, the Defense Resource Management System 
is being implemented throughout the MOD. The Defense Management Accounting 
System is designed to assist the newly proposed Defense Resource Management 
System. The objective of this system (procedure) is to provide standardized data for 
resource management to each level commander. [Refs. 7,8] Accounting information 
has two major purposes : decision making and performance evaluation. For example, 
managers can easily decide the proper disposal time of an equipment by using the 
accounting information. Regression analysis is one of the common techniques to 
produce the accounting information. 

The Defense Management Accounting System is intended to support not only 
the decentralized unit resource management system, which is one of the eight major 
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functions of the budget revolution movement, but also the PPBEES which is the mam 
objective of the defense management system. 

Until 1984, legal accounting procedures had been used to provide the legal result 
of resource expenditures. The private sector's accounting theory was adjusted to meet 
the characteristics of military needs. The analysis of performance and resource 
spending results can now be obtained through cost analysis. 

To accomplish this new accounting procedure, the Budget Revolution Committee 
adopted the unified accounting system based on the double entry bookkeeping 
principle. Everything that has any economic value must be recorded and analyzed 
according to the proposed accounting system. For example, suppose that there is a 
useful plant on the base; the monetary value of the plant must also be evaluated 
according to its growth, so annually, or at every prescribed term period, its value must 
be reevaluated. 

Two different kinds of accounting methods are used, according to the type of 
unit. The corporate accounting system (also called special accounting) is adapted to 
production, maintenance units and education units. On the other hand, general 
combat units use a different accounting system from the corporate accounting system. 
This is called the general accounting system and is similar to U.S. Government 
accounting procedures. 

The general accounting system does not permit the concept of depreciation, 
which is regarded as an expenditure at the time of disposal. Prepayments are also 
regarded as expenditures not as assets, which make up the capital. In the general 
accounting system, bonus payments are recognized at the point of occurrence, but in 
the special accounting system, the average of payments is recorded as expenditures in 
each period. Classification of expenditure as direct and indirect is needed in the special 
accounting system but not in the general accounting system. 

C. CURRENT RESOURCE MANAGEMENT SYSTEM 

Resource management system (RMS) are a series of systems designed to promote 
better management through the ROK MOD by providing managers with improved 
means of obtaining and controlling the resources required to accomplish missions. 
They also include procedures which are closely related to quantitative systems even 
though the system may not themselves be primarily quantitative. Resources are men, 
materials, services, and money. 
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A resource manager is any individual who is responsible for carrying out a 
significant mission or function and who in so doing makes decisions that have a 
significant effect on the resources used. For the military commander this means that 
responsibility for management is added to the traditional responsiblity for command. 

1. Objectives of RMS 

The objectives of RMS are: 

• to provide managers at all levels within the ROK MOD with information that 
will assist them in assuring that resources are obtained and used effectively and 
efficiently in the accomplishment of MOD objectives. 

• to provide information that useful in the formulation of objectives and plans. 

• to provide data to support program proposals and requests for funds. 

• to provide a means of assuring that statutes and other requirements relating to 
resources are complied with. (Ref. 8: p. 11] 

2. Structure of RMS 

The structure of RMS is designed to establish the criteria of each management 
accounting unit and lead each unit to have responsibilities for its resources and 
consumption of the resources. Through the structure of RMS it can be possible to 
measure the resource requirements that each management accounting unit needs, to 
motivate a resource manager by comparing with the performance of other unit, and to 
vest the authorities and responsibilities of resource management in resource managers. 

The structure of RMS consists of five levels, such as command and control 
unit, mid-management unit, resource management unit, expense collecting unit and 
consuming unit as shown in figure 2.2. (Ref. 8: p. 20] Higher level unit controls lower 
level unit and lower level unit report to the higher level. 

a. Command and Control Unit 

Command and control unit is the top management level which collects, 
analyzes, and evaluates all kinds of reports, determines the standard expenses, and is 
concerned with establishing policies and developing plans. Ministry of Defense (MOD) 
and ROKA Headquarters are the command and control units. 

b. Mid-level management unit 

Mid-level management unit is the second highest management level that 
collects various reports from subordinate units, puts the reports together, and reports 
them to the command and control unit. Headquarters of Field Army and Corps are 
mid-level management units. Mid-level management unit becomes a management 
accounting unit and has a responsibility for the resource management and reporting to 
the higher level. 
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Figure 2.2 Structure of RMS. 



c. Resource Management Unit 

Resource management units are the principal and elemental units of 
resource management which are concerned with estimating budget requirements; using 
and controlling resources, and producing various managerial data and reports. It has a 
responsibility for reporting to the higher level. Typically, Army divisions become 
resource management units. 
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d. Expense Collecting Unit 

Expense collecting units are the subordinate unit of resource management 
units, such as Infantry Regiments, which record various operating expenses, prepare 
periodic reports, and report to the resource management unit according to directions 
and coordinations of the upper level unit. 

e. Consuming Unit 

Consuming units are the lowest subordinate units of expense collecting 
units, these are usually companies. The consuming unit records all kinds of expenses 
whenever consuming events occur and report to the expense collecting unit through the 
simplest channels, such as telephone, oral message, messengers. 

f. Unit Identification Code 

Unit identification code is designed to computerize the processes that 
continuously accumulate all the expenses resulting from using the resources of a unit. 
In the resource management system for operations the unit identification code is the 
basic classification device whereby expense information is related to a program. ROK 
MOD makes the unit classification code and manage it and the unit classification code 
is created in a manner as shown in Figure 2.3. [Ref. 8: p. 21] 



Mid-level 
management unit. 

Type of unit 



1 

T 



Resource management unit, 
expense collecting unit 



Figure 2.3 Unit Classification Code. 

3. Accounting Records and Files 

Accounting records required under RMS are made up of ledgers, journals, 
basic cost records, and control records. The number and kinds of journals, ledgers, and 
other documentation records required depend upon the type and volume of 
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transactions, the desires of the major claimant, and the nature and level of the unit 
mission and organization. 

The general ledger is the book of accounts in which all accounting entries are 
ultimately summarized. A general ledger is maintained for each unit activity. The 
account structure in the general ledger is specifically designed to accumulate financial 
data necessary to render meaningful reports to management. The chart of accounts 
carried in the general ledger is shown in Figure 2.4. [Ref. 8: pp. 25 - 69] Not all 
accounts listed will be found in all general ledger; Only those used by the unit activity 
holding the operating budget are found in the general ledger at that unit activity. 



Major Classification 


Account 


series 


Asset accounts 


1000 - 


1999 


Liability accounts 


2000 - 


2999 


Capital accounts 


3000 - 


3999 


Budgetary accounts 


4000 - 


4999 


Contra accounts 


5000 - 


5999 


Expense accounts 


6000 - 


7000 



Figure 2.4 Chart of Accounts. 



4. General Procedure of Resource management Accounting 

Resource management accounting procedure is a series of processes that 
consists of identifying transaction, recording transaction, accounting process, closing 
entry, and preparing reports as shown in Figure 2.5. [Ref. 8: p. 74] 

a. Identifying Transaction 

A transaction means an activity that is recognized as accounting events 
associated with resources of a unit. In general, events are recognized as transactions 
only if they receive, transfer, release, or consume resources. 

b. Recording Transaction 

A resource transaction slip (RTS) is recorded whenever transactions occur. 
RTS is a kind of computer input document designed to process various resource 
transactions through a computer as shown in Figure 2.6. [Ref. 8: p. 153] 
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Figure 2.5 Resource Management Accounting Procedure. 

The results of consumption of the expense collecting unit and various 
resource transactions (supply transaction, budget transaction, maintenance transaction, 
gratuitous transaction, allotment transaction, and others) are recorded in RTS. 
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Figure 2.6 Resource Transaction Slip. 



c. Accounting Process 

In this stage, resource transaction slips are examined and modified when 
omissions, overlaps, or errors are found. A transaction file is produced by inputing all 
the resource transaction data. A Journal file is created from the transaction file 
thereafter. All the transactions of the journal file are recorded in the general ledger and 
each subsidiary ledger. 

d. Closing accounts 

Closing accounts is a procedure for preparing a trial balance, adjusting 
entries and various reports at the end of each quarter or year. A trial balance is a 
listing of each of the accounts in the general ledger with its balance at a particular 
time. All accounts with debit and credit balances are listed and summed. Closing 
accounts occur quarterly and yearly. 

e. Preparing Report 

Reporting is one form of responsibility accounting. The commanding 
officer (CO) has at his disposal a number of management and financial reports under 
RMS. Some reports are used by the CO; others are forwarded to the management 
echelon. 

Reporting provides information on the operating expenses and obligations, 
operating budgets, and performance of field activities. 

Reports forwarded upward are briefly listed in Figure 2.7. [Ref. 8: p. 86] 
Reports for the CO are very flexible depending upon characteristics of a unit, but now 
they are not established well in current RMS. 

5. Current computer flowchart of RMS 

A computer-based system was regarded as the key tool in the successful 
implementation of RMS, and each resource management unit (Army division level) was 
linked to the computer mainframe. However, the computer system for RMS was 
installed without sufficient preparation and experience, and it is undergoing deficiencies 
in its operating system and is not meeting the total user's needs. Current computer 
flowchart of RMS is shown in Figure 2.8. [Ref. 9: p. 7] 

D. LIMITATIONS OF CURRENT RMS 

The importance of MIS as an efficient tool to carry out the PPBEES system was 
perceived and the distributed computer system was implemented at the Army division 
level by the end of 1986. The computer is now used to perform the resource 
management work, but at the primitive stage. 
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NO 


REPORT NAME 


CONTENTS 


1 


Balance Sheet 


* All assets and resource 
transactions of a unit. 


2 


Operating 

expense 

report 


* Operating performance and 
expense of the unit s 
resources. 


3 


Expense 

management 

report 


* Total amount of each 
expense elements. 

* Comparison of each unit s 
expenses. 

* Expense data of each 
equipment. 

* Expense data of each 
facility. 


4 


Equipment 

management 

report 


* Operating performance 
or each equipment. 

* The present condition of 
each equipment. 


5 


Facility 

management 

report 


* The present position 
of each facility. 


6 


Material 

management 

report 


* The present position of 
each unit s materials. 

* Material transaction 
and its performance. 


7 


Budget control 
report 


* Performance of use 
of cash and budget. 



+ Responsible Unit: Resource Management Unit. 
+ Term of each report: Quarterly. 



Figure 2.7 Reports forwarded upward. 



The ROK Army is striving to improve the efficiency and effectiveness of its 
defense resource management. However, it is experiencing some problems in the RMS 
which is caused by insufficient preparation and inexperiences in its early stage. 
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Figure 2.8 Flowchart of RMS. 

1. MIS and Data Analysis Models 

Decentralized management system, one of the eight major functions to 
implement the PPBEES system, is highly recommended for use in the ROK Army. 
Every unit is classified into eight unit categories: combat unit, logistics & support, 
intelligence, communication, headquarters & administration, hospital, school/institute. 
Each unit has its own mission and characteristics, therefore each unit must have its 
own budgeting, controlling, and evaluating system. To get the useful information for 
decision making, each unit must have its own MIS. 
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However, in current RMS a different unit has the same ready-made MIS 
which is developed in the highest echelon. Because the current MIS was developed to 
be suitable for Army division level, the Korea Army has experienced many difficulties 
in applying the current MIS to the different kind of unit. 

Similarly, because each unit does not have the specific and well-developed 
analysis models, there is no way to compare the performance of each unit to the other. 
In order to compare and evaluate the performance, each unit must have its own MIS 
and data analysis models that is possible to get the useful information for decision 
making. 

2. Financial Data and Operational Data 

Management information helps the resource manager of each unit to make the 
best decision and it is produced, processed, and used through MIS. Management 
information can be divided into two classes: financial data and operational data. The 
Korea Army gets the financial data through the management accounting and can 
obtain the operational data by using or applying statistical theories and techniques. 

The operational data is, in a sense, more important than the financial data, 
because it is closely related to a more effective measurement - combat material 
readiness and availability. However, the current RMS does not provide sufficient 
operational data even though the Korea Army has a requirement to maintain the 
reliable operational data which can explain the activities or purposes of the 
expenditure. 

Data analysis models could not be developed without sufficient and reliable 
operational data. Furthermore, the combat material readiness and availability could 
not be measured well without the data analysis models. This problem was moreover 
complicated by using a unified single format RTS to record all the resource expenditure 
data of the unit which is discussed next paragraph. 

3. Resource Transaction Slip (RTS) 

RTS was designed to collect and accumulate all the data about the uses of 
each unit resources by the Defense Budget Revolution Committee, but it contains 
intrinsic problems in its use. 

An Army division has seven classes of floating assets by and large: (1) cash, 
(2) foods, (3) petroleum & oil, (4) ammunitions, (5) repair parts, (6) individual 
maintenance materials, & (7) troop maintenance materials. The expenditures and 
transactions activities on each resources should be recorded in a separate relation, 
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according to its unique characteristics. However, the 7 categories of the resources are 
required to be recorded in the single format of RTS. 

The RTS has only 30 items to be described. The 30 items can not include all 
the facts that are needed to process information for decision making. Only a few Of 30 
items are actually used in recording one transaction or activity of the resources, that is, 
the rest of 30 items is not necessary and redundant. 

With the current RTS, it is impossible to calculate all the training expenses 
including petroleum & oil, repair parts, individual or troop maintenance materials, 
ammunitions, and cash that are used in the regiment combat training (RCT). 
Additionally, it is impossible to know the operational performance of the various 
vehicles of each unit, and to accumulate the operating expenses of each unit facilities. 

The RTS is the source of all the data needed in the resource management 
system. However, the data gathered by the RTS are not entirely useful for the 
performance evaluation, problem identification, retirement decision of a equipment, 
and readiness or availablity measurement of each unit. Data do not have any value in 
themselves, but the value is determined depending upon the objective of data and how 
they are used in the analytical models. 

In order to acquire the most useful information for decision making, the 
analytical models are developed and established, but more important thing is to 
analyze the data requirement. Therefore, the RTS should be redesigned to meet the 
information requirement resulting from the proper analysis of data requirement. 

E. SUMMARY 

The Republic of Korean Military has begun to recognize the need for budget 
revolution because the U.S. Military Aid Program has greatly diminished since 1970's. 
It has adopted a newly designed defense resource management system (DRMS). The 
objective of DRMS is to achieve efficiency and effectiveness in military spending by the 
use of a newly-designed PPBEES, new staff structure, modem financial accounting 
techniques, program management system, management information system, and a new 
organizational approach. 

In this chapter we have reviewed the new DRMS implemented completely at the 
beginning of fiscal year 1986 and discovered the limitations of DRMS; (1) negligence of 
operational data that is indispensable for analysis and evaluation system, (2) unsuitable 
and insufficient data collection method, and (2) no data analysis models, caused by the 
insufficient preparations and inexperiences. Because of those limitations, the current 
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DRMS could hardly meet the initial purpose which was to create the performance 
criteria and decision-making information for each unit's efficiency and effectiveness 
mentioned above. This background will aid in understanding the main point of this 
paper: The database approach of DRMS at ROK Army division level. 

The next chapter will develop the information requirement of ROK Army 
resource management system which is able to achieve the original goals of DRMS. The 
information requirement must be analyzed to meet all the needs of current 
management information system and data analysis models that will be developed in the 
future. 
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III. INFORMATION REQUIREMENT FOR THE DRMS OF ROK ARMY 

A. CONCEPTS AND PROCEDURES OF INFORMATION REQUIREMENT 
DETERMINATION 

Correct and complete information requirements are key ingredients in planning 
organizational information systems, implementing information systems applications, 
and building databases. Major information system applications integrated with 
databases require careful planning and significant cooperative effort between users and 
information system professionals. 

Information requirement determination is a vital part of this cooperative activity. 
Although users are the fundamental source of requirements, they often lack the 
experience to accurately define them. Inexperienced analysts often feel that users 
should tell them what the information requirements are so system design and 
implementation can be developed. Experienced analysts know that eliciting correct and 
complete requirements is one of their most challenging tasks. 

Since a database management system must ultimately provide service for end 
users, careful attention should be given to their needs. The users may be anyone 
outside the organization, operational management, high level management, or any 
combination of these. Interviews with the users should be done during the design stage 
and also when the first phases of implementation are completed to solicit feedback for 
modification of the system. If the data base management system does not meet the 
user's needs, then it will fail no matter how clever and sophisticated the technical 
design. 

Information requirements are required at the organization-wide level for 
information system planning, identifying applications, and planning an information 
architecture. More detailed information requirements are required for design of 
applications. 

How can accurate and complete information requirements be identified? Because 
of the constraints on humans as specifiers of information requirements, the users can 
not identify them all. Eliciting correct and complete requirements is one of the most 
challenging tasks. Both users and analysts should better understand the process of 
determining information requirements and improve their performance in this area. 
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An information system should meet the needs of the organization it serves, and 
applications should meet the needs of their users. The requirements for the information 
system are therefore determined by the strategies, goals, procedures, and behavior of 
individuals within the organization acting individually and collectively. [Ref. 10: p. 
474], 

In order to effectively analyze organizational information requirements, a four 
step process is presented: 

1. Three level of information requirements 

2. Analysis of organizational information requirements 

3. Strategies for determining information requirements 

4. Selecting a strategy for determining information requirements 

1 . The Three Levels of Information Requirements 

There are three levels at which information requirements needs to be 
established in order to design and implement computer-based information system: 

a. The organizational information requirements to define an overall information 
system structure and to specify a portfolio of applications and databases. 

b. The requirements for each database defined by data models and other 
specifications. 

c. The detailed information requirements for an application. 

a. Organizational-Level Information Requirements 

Information requirements determination at the organizational level is a key 
element in developing an information system master plan. The process of 
organizational level information requirements determination obtains, organizes, and 
documents a complete set of high-level requirements. The requirements are factored 
into databases and subsystems that can be scheduled for development. The overall 
information architecture is defined, and the boundaries and interfaces of the individual 
application subsystems are specified. 

b. Database Requirements 

Database requirements arise both from applications and ad hoc queries. 
The overall architecture for the databases to meet these requirements can be defined as 
parts of organizational information requirements. Major classes of data are defined 
and associated with organizational processes that require them. There is very little 
detail in the requirements at this level. 
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The process of obtaining and organizing more detailed database 
requirements can be divided into defining data requirements as perceived by the users 
and defining requirements for physical design of the databases. User requirements are 
referred to as conceptual or logical requirements because the user views of data are 
separated from the organization of data in physical storage. User requirements may be 
derived from existing applications or by data modeling, 
c. Application-Level Information Requirements 

An application is a subsystem of the overall information system structure; 
it provides information processing for an organizational unit or organizational activity. 
The process for the determination of information requirements at the application level 
defines and documents specific information content plus design and implementation 
requirements. 

There are two types of information system application requirements: social 
and technical. The social or behavioral requirements, based on job design, specify 
objectives and assumptions such as the following: 

• Work organization design objectives 

• Individual role assumptions 

• Responsibility assumptions 

• Organizational policies 

The technical requirements are based on the information needed for the job 
or task to be performed. They specify outputs, stored data, and information processes. 
A significant part of the technical requirements are associated with the structure and 
format of data. The technical requirements include interface requirements between the 
user system and the application system. The interface requirements include data 
presentation format, screen design, user language structure, feedback and assistance 
provisions, error control, and response time. [Ref. 10: pp. 475 - 476]. 

2. Analysis of Organizational Information requirements 

Once goals and strategy have been delineated, the next stage is to obtain 
organizational information requirements. Although the level of specification is different 
for the organization and application, many of the methods for obtaining requirements 
are the same. Obtaining organizational information requirements consists of several 
steps: 

a. Define underlying organizational subsystems 

b. Develop manager by subsystem matrix 

c. Define and evaluate information requirements for organizational subsystems 
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a. Define Underlying Organizational subsystems 

The first phase of analysis is to define underlying organizational 
subsystems. The purposes of activity subsystem identification is to subdivide 
requirements determination by major organizational activity and make the process 
more manageable. The subsystems are obtained by an iterative process of discussing all 
organizational activities with managers and defining the activities as belonging to 
broad categories of subsystems. As new activities are considered, they are placed in 
previously defined categories, or a new category is created. 

b. Develop Subsystem-manager Matrix 

Once the underlying organizational subsystems are defined, the next phase 
of the organizational information requirements analysis is to relate specific managers to 
organizational subsystems. The matrix is prepared by reviewing the major decision 
responsibilities of each middle to top level manager and associating decision making 
with specific subsystems. The matrix identifies the major decision-making 
responsibilities for each subsystem. The purpose of this step is to clarify responsibilities 
and identify those managers to be interviewed relative to each subsystem. 

c. Define and Evaluate Information Requirements for Organizational Subsystems 

This step obtains the information requirements of each organizational 

subsystem by group interviews of those managers having major decision-making 
responsibility for the subsystem. Merely asking managers to define their information 
requirements is frequently not satisfactory because of the limitations on humans as 
information processors. It is therefore necessary to provide some structure to aid 
managers in thinking about information requirements. 

The questions used in eliciting information requirements are derived from 
three approachs. These questions reflect three ways of thinking about requirements, 
but each question also delineates unique requirements. The use of the three types of 
questions therefore increases the probability of obtaining a complete set of 
requirements. The three questions are: 

• What problems do you have and what information is needed for solving them? 
What decisions do you make and what information do you need for decision 
making? 

• What factors are critical to the success of your activity and what information 
do you need to achieve success in them or monitor progress? 

• What are the outputs (the ends) from your activities and what information do 
you need to measure effectiveness in achieving the outputs? What resources are 
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used in producing the outputs and what information is needed to measure the 
efficient use of resources? [Ref. 10: pp. 460 - 462) 

3. Strategies for Determining Information Requirements 

A strategy was defined as an approach for achieving an objective. There are 
four strategies for determining information requirements: 

a. Asking directly 

b. Deriving from an existing information system 

c. Synthesizing from characteristics of the utilizing system 

d. Discovering from experimentation with an evolving information system 

a. Asking Directly 

In an asking directly strategy, the analyst obtains information requirements 
from persons in the utilizing system solely by asking them what their requirements are. 
From a conceptual standpoint, the asking directly strategy assumes that users can 
structure their problem space and overcome or compensate for biases due to 
concreteness, recency, small sample size, and unused data. Anchoring by users in 
formulating responses is assumed to yield satisfactory results. These conditions may 
hold in very stable systems for which a well-defined structure exists or in systems 
whose structure is established by law, regulation, or other outside authority. There are 
a variety of methods for carrying out an asking strategy. 

If a pure asking directly strategy is followed, one or more asking methods 
are used to elicit requirements, and analysis is limited to consistency checks as 
requirements are documented, the asking methods can also be used in conjunction with 
other strategies. 

b. Deriving from an Existing Information System 

Existing information systems with an operational history can be used to 
derive requirements for a proposed information system for the same type of 
organization or application. Types of existing information systems that are useful in 
deriving requirements for future systems are: 

• Existing system that will be replaced by the new system 

• Existing system in a similar organization 

• Propriety system or package 

• Descriptions in textbooks, handbooks, industry studies, etc. 

With regard to human problem-solving behavior, deriving from an existing 
information system is an explicit use of anchoring and adjustment. Users and analysts 
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explicitly choose an existing system as an anchoring and adjust the requirements from 
it. Driving information requirements from an existing information system has also been 
termed a data analysis approach since the data inputs and outputs of the existing 
system are the focus of analysis. 

If the information system is performing fairly standard operations and 
providing fairly standard information for stable utilizing systems, the use of an existing 
system as an anchor is appropriate. In application systems for some well-defined 
functions such as payroll, data analysis of an existing system can be a useful primary 
method. In the early application of computers to organizational transaction processing 
and accounting system, derivation of requirements from the processing performed on 
the data provided by the existing system was widely used. 

Some analysts use data analysis of the existing system as a secondary 
method for deriving requirements. To avoid being overly influenced by the concreteness 
of the existing system, they may delay its use until after their primary analysis method 
has provided an initial set of requirements. 

c. Synthesis from Characteristics of the Utilizing System 

Information systems provide information services to facilitate the operation 
of object systems, those that utilize the information. Requirements for information 
thus stems from the activities of the object system. This suggests that the most logical 
and complete method for obtaining information requirements is from an analysis of the 
characteristics of the utilizing system. This approach may overcome biases by providing 
an analytical structure for the problem space of the user or analysts. The object system 
analysis is therefore appropriate when the utilizing system is changing or the proposed 
information system is different from existing patterns (in its content, form, complexity, 
etc.), so that anchoring on an existing information system or existing observations of 
information needs will not yield a complete and correct set of requirements. 

d. Discovering from Experimentation with an Evolving Information System 

Traditional procedures for determining information requirements are 

designed to establish a complete and correct set of requirements before the information 
system is designed and built. In a significant percentage of cases, users may not be able 
to formulate information requirements because they have no existing models on which 
to base requirements. They may find it difficult to deal in abstract requirements or to 
visualize new systems. Users may need to anchor on concrete systems from which they 
can make adjustments. 
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Another approach to information requirements determination is, therefore, 
to capture an initial set of requirements and implement an information system to 
provide those requirements. The system is designed for ease of change. As users employ 
the system, they request additional requirements. After initial requirements establish an 
anchor, additional requirements are discovered through use of the system. The general 
approach has been described as prototyping or heuristic development. [Ref. 10: pp. 
480 - 488] 

4. Selecting a Strategy for Determining Information Requirements 

Four strategies have been described for determining information requirements, 
with each strategy having a number of methods that may be employed. The selection 
procedure is contingent on characteristics of the environment in which the 
determination of requirements is conducted. 

The underlying basis for selecting a strategy is uncertainty with respect to the 
requirements determination processes. The uncertainty is based on four factors: 
characteristics of the utilizing system, the information system or application, the users, 
and the analysts. 

The approach to selecting an information requirements determination strategy 
consists of five steps as shown in Figure 3.1. [Ref. 10: p. 489] 

The steps represent a series of evaluations to establish a basis for selection. 
The evaluations are not precise, but do provide guidelines for judgment. The steps are 
listed as follows. 

1) Identify those characteristics of the four elements in the development process 
that affect uncertainty in the determination of information requirements: 

• Utilizing system 

• Information system or application 

• Users 

• Analysts 

2) Evaluate the effect of the characteristics of the four elements in the 
development process on three process uncertainties: 

• Existence and availability of a set of usable requirements 

• Ability of users to specify requirements 

• Ability of analysts to elicit and evaluate requirements 

3) Evaluate the combined effect of the process uncertainties on overall 
requirements uncertainty. 
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Figure 3.1 Selection of a Strategy. 







4) Select a primary strategy for requirements determination based on the overall 
requirements uncertainty. 

5) Select one or more methods from the set of methods to implement the primary 
strategy. [Ref. 10: p. 490] 

B. INFORMATION REQUIREMENTS FOR DRMS OF ROK ARMY DIVISION 

LEVEL 

As we mentioned in the previous chapter, the Defense Budget Revolution 
Committee was established in order to make an intrinsic improvement in the defense 
budget system. The committee selected eight major functions to implement the 
PPBEES system: 1) decision making process; 2) planning programming process; 3) 
project management system; 4) decentralized management system; 5) computer-based 
management information system; 6) analysis and evaluation system; 7) resource 
management staff function; and 8) reorganization. 

Among the eight major functions, decentralized management system is considered 
as the most important and critical function at the army division level. A decentralized 
management system leads a resource manager (commanding officer) to improve the 
efficiency and effectiveness of all the resource utilizations and produce various data 
credibly that high-level units need. 

Because management means a boundless decision-making process and the 
decision making is based on the proper information, a decentralized management 
system depends heavily upon the quality of management information system of an 
army division. The information and data are only of use when they are used in decision 
making. The data gathered without considering the users' needs, evaluation criteria, 
and decision support models will not provide useful information. While this type of 
data is "nice-to-know", it is of no use as an aid to analysis or decision making. The 
information which army division as a resource management unit should produce for its 
own use and high-level unit's needs may differ according to the type or kind of decision 
making, that is, different kinds of decision making requires different information. 

Decision making may be conducted by rule of thumb from data gathered in the 
simple cases, but in the more complicated cases a decision support model must be used 
to get useful information for decision making. Therefore, data gathered should be 
suitable for the decision support models or data analysis models. 

The major premise of the decentralized management system is performance 
measure. Fair performance major is the best tool to motivate the resource manager of 
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each unit. Resource manager's behaviors may be changed according to the 
performance criteria (motivation device) that will be decided. Resource managers may 
operate and lead their unit to be evaluated their performances highly comparing to the 
established performance criteria. Therefore, in order to determine correct and complete 
information requirements, decision-making types, decision support models, and 
performance criteria should be selected before anything else. The analysis of 
information requirement determination is the most important step in structuring the 
management information system. 

The requirements for routine transaction processing at the army division level 
might be stable and relatively easy to identify. However, informantion requirements for 
management and decision making activities would be more changeable and more 
difficult to define. To identify current and complete information requirements at the 
army division level, it is rational to survey or interview the various in each functional 
group: the asking directly strategy is suitable for determining information requirements 
at the army division level. 

1. General Information Requirements 

In the previous chapter, we identified the limitations of defense resource 
management system (DRMS); (l) negligence of operational data that is indispensable 
for analysis and evaluation system, (2) unsuitable and insufficient data collection 
methods, and (3) no decision support models. To overcome those limitations of 
DRMS, the authors try to change the data collection methods based on new 
information requirements, build the database of DRMS at the army division level, and 
encourage development of the decision support models in order to meet the initial 
objective of DRMS. 

As mentioned above, the information requirement determination is the critical 
step. The information requirements must meet the needs of all kinds of decision 
making, performance measures, decision support models, and existing information 
systems. In order to meet these needs, we developed general information requirements 
for the army division level. They are the information requirements that should be 
accepted in the future to achieve the objective of DRMS at the army division level. 

The general information requirements created by authors are listed and 
explained as follows: 

a) Evaluation of each responsible manager's performance. 

b) Calculation of the expense of each unit activity. 

c) Measurement of each training costs. 
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d) Derive the expense coefficient of each equipment per operating hour. 

e) Accumulate the operating and maintenance cost of each equipment by each 

model and each production year. 

0 Estimation of the life cycle cost of combat urgent equipment. 

g) Measurement of the changes in inventory of each unit. 

h) Calculation of the logistic support capability. 

i) Production of the other data for availability and combat readiness. 

a. Evaluation of Responsible manager's performance 

To increase the efficiency and effectiveness, each responsible manager's 
performance is evaluated and compared with the other managers. The performance 
criteria must be developed to conduct a performance measure of each responsible unit. 
Information requirements for evaluating each responsible manager's performance must 
be included in the new r ly designed database system ( called new system below). 

b. Calculation of Expenses of Each Unit Activity 

This calculation of the expenses of each activity also will provide useful 
information for commanding officers about how the defense resources should be 
allocated to maximize the effectiveness of resource utilization in each activity. The 
expenses of each activity should be collected to two classes; fixed expenses and variable 
expenses and we must derive the types of relationships among them. 

c. Measurement of Each Training Costs 

The objective of measurement of each training costs (i.e., petroleum & oil, 
repair parts, materials, cash etc.) can induce resource managers to consider the cost- 
benefit analysis of each training. Training cost may differ depending upon the 
characteristics of each unit and regional conditions. Therefore, the measurement of 
each training cost will provide a criterion for each unit and each training in budgeting, 
allocating resources, and forecasting war time minimal resource requirements. 

d. Production of the Expense Coefficient of Each Equipment 

By using multiple regression technique, we can derive the expense 
coefficient 3 of each equipment used in different activity or objective. The expense 
coefficient can become a useful tool for finding out the recording errors in recording 
the expense of each equipment, a indicator that can shows the differences between each 
unit and each activity in operating equipments, and a useful criterion for selecting an 
optimal equipment. 

3 Expense coefficient is defined as the unit impact of each equipment on defense 
resources explained in detail in Chapter VI. 
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e. Measurement of O&M cost of each equipment 

One of the important policies in managing the organized equipment is to 
determine the economic repair limitation and the reasonable retirement time of each 
equipment. To do these, we need the data about the operating and maintenance costs 
of each equipment. Although this data may be used at a level higher than the resource 
management unit, the data must be gathered by the unit that operates the equipment. 
In the current system, this data is not gathered from the operating units directly and 
currently not required. But, this data must be gathered from the unit fields and 
required in the new system. 

/. Estimate of LCC of Combat Urgent Equipment 

The cost of combat urgent equipment is very expensive relative to other 
equipment. The estimate of life cycle cost (LCC) of each combat urgent equipment can 
provide a useful information in measuring the availability or combat readiness, 
forecasting the demands of combat equipment, and developing the adequate supply 
package of repair parts in war or peace time. 

g. Inventory Management 

To increase the efficiency and effectiveness in inventory management, 
inventory management models (i.e., EOQ: economic order quantity model) should be 
developed and a systemic device for controlling inventory transaction and finding out 
changes in inventory should be structured. 

h. Calculation of facility maintenance costs 

The analysis of facility maintenance costs also give decision makers useful 
information in planning and budgeting the total facility maintenance costs. We can get 
the standard maintenance cost per square meter for each facility from analysis of 
maintenance expenses. 

/. Evaluation of Logistic Support Capability 

A supply supported unit (army division level) must evaluate the logistic 
support capability (i.e., stockout items, supply lead time, unused materials, repair parts 
purchased from the civilian etc.) of the supply supporting unit (logistic command). By 
doing so, a supply supported unit can take reasonable actions to convert into a rapid 
supply system and be able to solve anticipated problems in war and peace time. 

2. Output Data List Based on Information Requirements 

Based on the general information requirements, the input data, processing 
models/software programs, and output formats will be determined. Output documents 
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produced by the new system will be based heavily on the general information 
requirements and contain the detailed information for decision making. They will be 
produced by data process associated with materials, cash transaction, and resource 
utilization in the computer system. 

Output documents will be classified into two classes; reports forwarded 
upward (external documents) and reports used inside (internal documents). External 
documents are reported to higher echelon, and are used in planning, programming, 
budgeting, and controlling defense resources. External documents are well developed in 
the current system as discussed in the previous chapter. 

Unfortunately, the current system of internal reporting is underdeveloped. 
Internal reports generated by the new system consist of useful information with which 
the commanding officers and staffs can manage the defense resources efficiently. 

In this paper, we will place their emphasis on the documents which are utilized 
within the army division level in order to assess management performance and 
stewardship, to get information on program activity and fiscal compliance, and to 
determine resource allocations. Internal documents are created by authors based on 
the general information requirements discussed above. These documents are listed as 
shown in Table 3 and are divided into three categories; inflow of resources and changes 
in inventory, resource utilization, and combat readiness measurement. 

3. Specific information requirements 

The timely, accurate, and relevant information enable management to evaluate 
management performance, to determine resource allocation and to make good 
decisions. To get timely, accurate, and relevant information, the authors defined first 
the general information requirements and then produced the documents based on them. 
Now the authors define the specific (detail) information requirements of each document 
that will satisfy the needs of management. 

The authors identify the subcategories of information (data elements) and 
purpose of each documents in Appendix A. 
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TABLE 3 

NEWLY-CREATED INTERNAL DOCUMENTS 



Classification 


Document Name 


Inflow of 
resources and 
changes in 
inventory 


* Unit supply transaction & assets 

* Total unit resources report 

* Unit changes in inventory report 

* Unit resource D / 0 report 


Resource 

utilization 


* Unit activity expense report 

* Unit resource utilization report 

* Budget allocation and expenditure 

* Cash disbursement report 

* Cash disbursement by activity 

* Equip, expense coefficient report 

* Equip, operation by activity 

* Operating performance by equipment 

* Unit training cost report 

* Facility maintenance cost report 


Combat readiness 
measurement 


* Combat equipments 
average life analysis 

* Supply support required time 
analysis 

* Inventory stockout report 

* Combat urgent equipment and 
repair part stockout report 



C. SUMMARY 

Information requirement determination is the starting point in planning an 
organizational information system, in implementing systems applications, and in 
building a database. To determine correct and complete information requirements, 
decision-making types, decision support models, and performance criteria should be 
selected before determination of information requirements. 

Unfortunately, decision-making types and decision support models are not well 
defined and developed at the ROK Army division level. Therefore, the authors 
determined the information requirements for DRMS at the army division level based 
on their judgment and experiences. 
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The new system which will be redesigned in the future should satisfy the 
following general information requirements: 

• Evaluation of the each responsible manager's performance. 

• Calculation of the expense of each unit activity. 

• Measurement of the each training costs. 

• Derivation of the expense coefficient of each equipment per operating hour. 

• Accumulate the operating and maintenance cost of each equipment by each 
model and each production year. 

• Estimation of the life cycle cost of combat urgent equipment. 

• Measurement of the changes in inventory of each unit. 

• Calculation of the logistic support capability. 

• Production of the other data for availability and combat readiness. 

Based on the general information requirements, the authors created several 
internal documents, which will be useful for commanding officers to make decisions. 
Data contained in those documents can provide the information for the appropriate 
allocation of defense resources, give performance criteria for performance measure of 
each unit, and encourage to develop the decision support models. 

The next two chapters will discuss the design and manipulation of database that 
will make it possible to satisfy the information requirements of DRMS at the army 
division level and to overcome the limitations of current DRMS discussed in the 
previous chapter. 
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IV. REVIEW OF RELATIONAL DATA MANAGEMENT APPROACH 



A. DATA MANAGEMENT PHILOSOPHY 

Effective management of organizations, both private and public, depends on 
information concerning the organization's operations, finances, and the allocation 
of its resources. With such information management can control costs and 
maximize profits or operationaj efficiency. Such information also provides a basis 
for planning for future developments, i.e., new services, improved operations. 
[Ref. II: p. 3] 

It is widely recognized that data is the most valuable resource in an organization. 
Since the management of an organization requires a series of decision making activities, 
accurate and timely data plays a crucial role in making informed decisions. Data must 
be managed systematically to meet the user's needs; this is the cornerstone of the data 
management philosophy. 

1. Data as a Shared resource 

The scope of organizational activities is very broad and associated with the 
levels of management and functional activities. The most important aspect of 
management activities is decision-making. Information requirements vary by 
management level and organizational function, and use common data frequently. 

Each functional group could maintain independently the data unique to its 
decision making, however this might result in data redundancy and inconsistency from 
a global viewpoint. 

The ideal condition is that an organization shares data which is accessible to 
different users for different purposes. These data might be regarded as the raw material 
for producing meaningful information. This view supports the notion that information 
is an organizational resource. 

2. Data Independence 

The philosophy of data independence is concerned with the aspects of data 
storage and retrieval. Data independence means the separation of the user view of 
data (logical data model) from the physical storage of data (physical data model). 

When data independence holds, changes in either data model are possible 
without affecting the other. The database designer or user is allowed to change the 
storage structure or access strategy in response to changing requirements without 
having to modifying existing applications. 
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Data independence is extremely desirable because it potentially increases the 
applications which can use the same data. If data is dependent on the application 
(program), we have to separately create and maintain the data used in each case. 
However, in the case of data independence, different applications can use different 
views of the same data. 

3. Centralized Control 

An organization needs to integrate its data processing system with centralized 
control. If there are no integrating mechanisms, data items may be specified differently 
and cause inconsistent and incompatible descriptions. There may also be redundant 
development of separate applications when a single application could serve as well. 

Centralized control over an organization's operational data provides several 
advantages: 

• Reduced redundancy 

• Consistency of application 

• Improved data sharing 

• Enforced standards, integrity, and security 

• Reduced conflicting requirements [Ref. 12: pp. 10-12] 

B. DATA BASE MANAGEMENT SYSTEM (DBMS) 

Data needs to be managed systematically in order to be available to the user in a 
timely and accurate manner. A DBMS is a software system which makes the database 
concept operational. 

1. Difference between DBMS and File System 

Data base management systems can be distinguished from file systems by the 
level of functions they provide, as well as the degree of semantics attributed to the 
data. 

a. File system 

A file system, as the traditional approach to data, is often characterized by 
data redundancy and inconsistency. 

File systems may also obstruct an organization's growing demands for 
diverse application programs, because the practice of creating and maintaining separate 
files for each application tends to store no more data than are needed for the job at 
hand. 
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For user access and data integrity, a file system often does not provide 
adequate conditions. It stores data according to user-defined formats called records, 
and may or may not provide a directory of files on a per-user basis. Users share data 
by equally ad hoc means, generally by taking turns accessing the same device. 
b. Database Management System 

A DBMS provides a higher level of functions than a file system: 

• Contains more structured data: maximize accessibility, minimize cost 

• Provides a greater degree of data independence from the physical layout 

• Supports reliable recovery (back-up) and integrity 

• Enables interface with special applications or ad hoc queries 

Besides, users interact with the DBMS through language subsets, such as a 
data definition language and data manipulation language. Most DBMS provide a 
directory/dictionary at a higher, more user oriented level than file systems do. These 
details will be discussed in the following section. 

2. Functions of DBMS 

Since a database management system must ultimately serve the user's needs, 
the capabilities of DBMS have evolved continuously to provide a significant increase in 
availability, integrity, and consistency of data. Table 4 lists nine major DBMS 
functions which w'ere introduced briefly in the previous section. 



TABLE 4 

FUNCTIONS OF DBMS 

• Store, retrieve, and update data 

• Provide integrity services 

• Control concurrent processing 

• Support logical transactions 

• Recover from failure 

• Provide security facilities 

• Interact with communications control programs 

• Provide utility services 
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The DBMS must store, retrieve, and update data. In addition, the DBMS 
should provide integrity services to enforce constraints on the data. 

Maintaining a database with dozens of records and hundreds of data-items 
can be time consuming. Therefore, the usefulness of the data dictionary is increased if 
it contains not only data descriptions but also relationships between programs and 
data, e.g., which programs access which data, and what they do with it. 

Since a data base is a shared data resource, several users may try to access it 
simultaneously. To meet this situation, the DBMS must provide controls over 
concurrent operations. Actually, concurrent processing is not simultaneous because no 
two actions take place at the same time in a single CPU or DBMS. The DBMS 
controls processes which must be interleaved properly in order to preserve the correct 
data values. 

A logical transaction is a sequence of activities performed automatically. 
Usually, transactions include several actions on the database. However, the DBMS 
cannot know which groups of actions are logically related. Thus the DBMS must 
provide facilities for the application program to define transaction boundaries. 

The next two functions were already discussed in the previous section on DB 
requirements. The DBMS must be able to recover from failure, such as machine 
failures, disk crashes, berserk programs, and unenlightened users. A database is a 
valuable resource as well as a model of the current state of an organization. If the 
database is divulged to improper or unauthorized people, considerable damage can 
occur. To reduce the likelihood of such loss, the DBMS provides security facilities by 
which users can be defined and identified and authorization enforced. 

Additionally, the DBMS must interface with a communications processing 
system. Terminal users interact with a communications control program, which 
controls the flow of transactions to application programs which then call upon the 
DBMS. The final function of utility service is to facilitate database maintenance. 
People may not follow established procedures, and it may be necessary to determine if 
one copy of a database is identical to another. Also there may be a need to make mass 
insertions or deletions of data in or out of the database. [Ref. 13: pp. 401-406] 

3. DBMS-related Subsystems 

a. Data dictionary / directory system ( DD/DS) 

The DD/DS provides effective centralized control of organization data 
resources in a uniform manner. 
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A data dictionary, as a repository of information about data, represents a 
description of data stored in the database. The main information contained in the data 
dictionary includes the following: 

• Name of the data item 

• A description of the data item 

• Source of data 

• Impact analysis 

• Key words used for categorizing and searching for data item descriptions 
[Ref. 10: p. 505] 

The directory contains a physical map of the objects it stores ('where' and 
'how'), including the external name object, its characteristics, the authorization users 
have on it, and its relationships with or dependencies on other objects. 

The major objective of a DD/DS is to support the integration of metadata 4 
in much the same way that a DBMS supports the integration of an organization's data. 
The benefits achieved from the data dictionary are minimum redundancy, consistency, 
standardization, and metadata sharing. In addition, the integration of data describing 
the database allows the database administrator (DBA) to monitor data base content 
and to effectively enforce security and integrity policies. 
b. Database Query Language 

Query languages are specific to the database management system with 
which they are used. Each data base management system has its own query language 
with unique rules and instruction formats. 

Two usages of a data query language are for data processing and reporting 
applications, and ad hoc queries. The first case is oriented to programmers, such as 
COBOL, whereas ad hoc queries are sufficiently simple that they can be made by non- 
programmers. 

The most well known query language for relational systems is SQL 
(structured query language). SQL is a transform-oriented relational language which 
includes commands for data definition, data manipulation, and data control. In the 
next chapter, examples of data manipulation using SQL will be presented. 



4 Data about the data base: It includes description of the meanings of data items, 
the way in which the data are used, their sources, their physical characteristics, and 
other rules or restrictions on their forms or uses. 
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c. Database administrator {DBA) 

As database systems come into broader use and organizations gain 
experience in the use of such systems, the need for controlling the shared data and 
maintaining the integrity and security of the database becomes obvious. The DBA is 
assigned the administrative responsibilities that must be centralized as a result of data 
integration, and the technical responsibilities that are specifically related to the 
database and use of the database management system. 

The DBA is the primary liaison with the users of the data base. The DBA 
collects and maintains data about the data base and makes this information available 
to potential data base users. The DBA also maintains specialized software tools needed 
for data base use, such as data dictionaries, query languages, or design aids. The DBA 
may provide educational support for database users, on any or all database-related 
software. (Ref. 12: pp. 15-16] 

C. RELATIONAL DBMS 
1. Background 

Modern database management systems emerged from the mid-1970s. These 
systems have been developed to overcome the restrictions of previous DB systems and 
are characterized by interactive access capability. Several users can run different 
applications concurrently on the same data, and the database system will serialize these 
data manipulations appropriately. 

Trends in current data processing environments, such as the shortage of data 
processing professionals and the increasing backlog of applications, have motivated the 
development of database technology. This improves the productivity of data processing 
professionals by simplifying the database calls in the application programs they write. 
In addition, it makes it possible for non-DP professionals to specify their queries to an 
interactive query program and receive their answers on a screen or printer, thereby 
avoiding the development of an application program altogether. 

Relational database management systems manifest the tendency in database 
technology of providing easy access to data for people who are not data processing 
professionals as well as those who are. Relational databases provide a very simple, 
tabular view of data. Unlike the earlier hierarchical and network organizations, 
relational databases derive relationships from the data values rather than having 
explicit pointers between records. 
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2. Relational terminology 

Some terminology used frequently in describing relational systems is given 

below: 

• Relation: a two-dimensional table of data; flat files with rows and columns 

• Entity: any distinguishable object that is represented in the data base; 

conceptual representation of the primitive objects 

• Attribute: representation of properties of objects; columns of relation 

• Tuple: rows of a relation 

• Domain: the collection of all values that an attribute can have 

• Degree: the number of data items in the record type; number of columns 

• Cardinality: the number of rows or tuples in a relation 

• Null value: special values representing 'unknown' or 'inapplicable' 

• Key: the attribute or attributes with values that are unique within the relation 

and thus can be used to identify the tuples of that relation 

• Relationship: conceptual representation of an association among entities 

• Relational schema: a description of the structure of relations in a relational data 
base 

• Relational database: a database that is perceived by the user as a collection of 
time-varying, normalized relations 

3. Relational representation of data 

The relational model has the fundamental advantage of conceptual simplicity 
for a diversity of users in the application environment (casual user, programmer, etc.) 
who can communicate among themselves on the basis of such a unified framework. A 
model is the result of the abstraction of an event and is presented by a set of entities 
and relationships. During the process, relevant attributes of both objects and 
relationships are chosen and classified into various object types. 

Data in the relational model are represented by a relation viewed as a table. 
The table's heading defines the relation's name, and each row corresponds to an n- 
tuple of data values describing a single entity. Also, data in each column are assumed 
to arise from the same domain. A value of a given attribute may change over time, but 
it always belongs to the domain of that attribute. 

An example of the representation of a student entity type by a set of tuples 
and attributes is shown in Figure 4.1. 
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NAME 


CUR. 


SERVICE 


SMC 


Alice 


827 


USN 


1425 


Lee 


815 


USA 


1030 


John 


837 


USN 


2123 


Kim 


817 


ROKA 


2362 


Mary 


817 


USAF 


2551 



Figure 4.1 A STUDENT Relation. 

STUDENT - (NAME * CUR. * SERVICE * SMC) which represents that 
each student determines a unique tuple. Each entity can also be shown in Figure 4.2. 




Figure 4.2 Representation of STUDENT entity. 

4. Relational algebra 

As the expression 'algebra' implies, relational algebra is a way of manipulating 
relations by using a set of operators, such as select, join, projection along with others. 
Each operation of the relational algebra takes one or more relation(s) as its operand(s) 
and produces a new relation as the desired output. 
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Each operation of the relational algebra takes one or more relation(s) as its operand(s) 
and produces a new relation as the desired output. 

The operations are chosen in such a way that all well-known types of queries 
may be expressed by their composition in a rather straightforward way. The relational 
algebra includes union, intersection, difference, projection, restriction, join, and 
division. [Ref 14: p. 24] 

The first four algebra operations are similar to high school algebra, and we 
can call them the usual set operations, we will define and illustrate the other 
operations of relational algebra by using the STUDENT relation of the previous 
section. 

a. Projection 

Projection is an operation that selects specified attributes from a relation. 

Given a relation STUDENT, the projection STUDENT (NAME, CUR.) 
represents each student's curriculum, as shown in Figure 4.3. 



NAME 


Cur. 


Alice 


827 


Lee 


815 


John 


837 


Kim 


817 


Mary 


817 



Figure 4.3 Projection. 

b. Restriction (or selection) 

The restriction operator takes a horizontal subset and selects tuples to be 
included in a new relation. The restriction is defined by a logical condition with a 
rather simple expression. 

Given a relation STUDENT, student (Cur. = 817) represents the table of 
students who are in 'curriculum 817': 

c. Join 

The join operation is a combination of the product, restriction, and 
projection operations. We create another relation SERVICE as represented in Figure 
4.5. 
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NAME 


CUR. 


SERVICE 


SMC 


Kim 


817 


ROKA 


2362 


Mary 


817 


. USAF 


2551 



Figure 4.4 Restriction. 



NAME 


SERVICE 


RANK 


CUR. 


Smith 


USN 


LT 


837 


Ryan 


USN 


LCPT 


827 


Robert 


USA 


MAJ 


817 


Kim 


ROKA 


CPT 


817 



Figure 4.5 A SERVICE Relation. 

Given relations of STUDENT (Name, Cur., Service, Rank, SMC) and 
SERVICE (Name, Service, Rank, Cur.), STUDENT(Service= Service) 
SERVICE(Name, Service, Cur.) represents the composition of two operations: the join 
of the relations STUDENT and SERVICE via the attribute Service, and the projection 
of the result of the join operation on the attributes Name, Service, and Cur.. 

The result of the join operation is shown in Figure 4.6. 



NAME 


SERVICE 


CUR. 


Alice 


USA 


815 


Robert 


USA 


817 


Lee 


USN 


815 


John 


USN 


837 


Smith 


USN 


837 


Ryan 


USN 


827 


Kim 


ROKA 


817 



Figure 4.6 Join. 

5. Relational Query Language 

The relational algebra, as a basic means of retrieval of data, is not suitable as 
a practical query language for casual users of the database because it is too procedural. 
A number of relational query languages have been developed which are much simpler 
than the relational algebra in posing queries. 
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Among the query languages, SQL (structured query language, formerly 
SEQUEL), developed by IBM, is regarded as the most convenient and powerful. We 
will use SQL as the query language in all subsequent discussions. SQL is not just a 
query language, but it permits specification of other actions on the database, including 
commands for data definition, data manipulation and data control [Ref. 13: p. 265] 
SQL commands can also be embedded in application programs. 

The basic form of SQL is: 

SELECT <list of attributes > 

FROM < list of relations > 

WHERE < qualification expression > 

The first two clauses (SELECT, FROM) in the query block define the 
operation of projection. The qualification expression in the WHERE clause is a logical 
expression. It contains attributes of relations listed in the FROM clause and 
determines what tuples of those relations qualify for the operation of projection. This 
type of nonprocedural database language eliminates the need to specify access paths to 
the data. 

The result of execution of a query block is a relation. Query blocks may 
appear as operands of the set operations. SQL operations are enumerated as in the 
Table 5. 



TABLE 5 

EXECUTION OF QUERY BLOCK 

• Projection 

• Restriction (selection) 

• Join 

• Union/difference 

• Intersection 

• Division 

• Insertion/Deletion 

• Update 
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We will present a number of SQL examples using the following schema: 



(Name, Cur., Smc#) 

(Course#, Hour, Class room) 
(Name, Service, Rank) 

(Professor, Department, Course#) 



STUDENT 
COURSE 
SERVICE 
PROFESSOR 

a. Projection 

To obtain a list of students and their curricula: 

SELECT Name, Cur. 

FROM STUDENT 

b. Restriction ( selection ) 

To select all student whose curriculum is '817': 

SELECT * 

FROM STUDENT 

WHERE Cur. = 817 

* denotes selection of all attributes (columns) of the table STUDENT. 

To select a table of STUDENTs who have the rank Major or LCDR: 
SELECT * 

FROM SERVICE 

WHERE Rank = Major 

OR Rank = LCDR 

To display the class hours of course# taught by Professor A: 

SELECT Hour 



FROM 

WHERE 



COURSE 

Course# 



IN SELECT Course# 

FROM PROFESSOR 

WHERE Professor = A 

This example shows how embedding a query from one relation into a query 
of another permits implicit specification of the natural join operation. 



c. Join 

This query constructs a table of student's names, curriculum, service, and 
ranks. As a rather simpler case, this query block is a composition of two operations of 
relational algebra: projection and join. 



SELECT 



Name, Cur., Service, Rank 



FROM 



STUDENT, SERVICE 



WHERE STUDENT Name = SERVICE Name 
d. Other operations 

The ability of SQL query specification ranges far beyond the preceding 
examples. The other operations shown in Table 5 can also be constructed variations of 
the examples. Throughout the' SQL manipulation, considering the required output 
relation, the number and domain of the attributes should be well defined to facilitate 
the future operation. 

D. SUMMARY 

This chapter provided a conceptual overview of database management systems 
and relational data management technology. Since the availability of timely and 
accurate data is the key in any organizational activity, demand for a well-developed 
database is very high. The data management philosophy gives a rationale for database 
systems. 

A database system, as a mechanized and controlled data pool, provides many 
advantages that are not available in previous file systems: reduced redundancy; easy 
application; program-to-data independence; ad hoc query; integrity; security. 

A database management system (DBMS) is a set of software making the physical 
storage of data operational. A data dictionary/directory system, query languages, and 
database administration (DBA) are the major elements of the system. 

The relational database model is the most popular database technology in use 
today. Its flexible and powerful capabilities enable ordinary users to perform many 
queries using the relational query language. Some basic examples of SQL operations 
were introduced to illustrate relational concepts. In the next chapter, we will apply 
relational database technology to the resource management system. 
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V. DATABASE APPLICATION CAPABILITY 



Based on the information requirements for resource management identified in 
Chapter III, we will show a basic application of relational database technology. First 
we develop a logical design for the defense resource management environment, then 
derive the relations to be processed in the relational database, and finally illustrate the 
data manipulation required to generate an output (creation of new relation). We use 
the SQL data manipulation language introduced in the previous chapter. 

A. APPLICATION ENVIRONMENT 
1. Conceptual Issues 

A relational database is a set of relations (tables) whose structure is specified 
in the schema. The actual sets of tuples change over time due to various actions which 
are activated by the users in the application environment to reflect the changes that 
happen over time in that environment. However, only those changes (updates) of the 
relational database are accepted which perform in accordance with the integrity 
constraints. Users satisfy their information needs either by triggering prespecified 
transactions which represent composite queries and produce appropriate reports, or by 
stating ad hoc queries using user-friendly relational query languages. 

The activities in resource management are very complex and multi-faceted. 
The information required to make a sound decision for the optimal allocation of 
resources and to produce various analysis for future budgeting must be selected 
carefully through systematic data processing procedures. This implies two principal 
aspects of the data base design: 

(a) Which data should be collected and maintained in the database? 

(b) How can the required information be generated by users? 

Since we are dealing with the relational database model, the system should be 
developed to meet user's needs from the initial stage of relational design in order to 
maximize its flexibility for answering various queries. The designer must also establish 
priorities and make the best possible compromise in light of conflicting factors such as 
elimination of anomalies, relation independence, and ease of use [Ref. 13: pp.307-311]. 



63 



2. Prerequisite of relational database development 

In order to develop the resource database system, there are some prerequisites: 

• Establish a coding system 

• Establish a standard price system 

• Define a measurement units for the different classes of resources 

• Design a reporting document format 

A coding system is a crucial factor for data base processing and requires a 
considerable effort. All input data are recorded by using predefined codes, and the 
codes should encompass all resource activities throughout the division. Coding systems 
help to substantially reduce the amount of data to be stored. We use a preliminary 
coding system as shown in Appendix B. 

The standard price for each equipment/material is used to convert the amount 
transacted or resources expended into a money value primarily for the purpose of 
accounting. Identical price levels for an item contribute to consistent management of 
performance analysis and cost-effectiveness control of the unit. 

Since the division has so many kinds of resources with different units of 
measurement, it would be very confusing and impractical to record the measurement 
unit every time in the relation. So we need to decide a basic unit for each input data 
element, which can be configured automatically according to the resource code. 

As defined in Chapter II, the single format of the current report, called the 
Resource Transaction Slip, causes deficiencies in generating some operational data. The 
new report format should be designed to overcome this problem. It is recommended 
that the report prepared by the subordinate unit include all the required data items to 
meet the diverse information requirements and to exploit the advantage of relational 
DBMS. Considering the multifaceted resource activities and database input format, the 
redesigned report should be developed separately for each resource class and activity 
rather than as a single uniform report. 

B. LOGICAL MODEL OF THE DRMS 

Designing the DBMS for DRMS is divided into two phases: logical and physical 
design. Before getting into the specific matters of database design, the designer needs to 
review the environment of the system and the user's information requirements. 
Through a series of abstraction processes, the designer can identify the relationships of 
the individual data to be stored. This process is called a logical design. Then, based on 
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the result, the designer builds a physical design, where the logical design is developed 
into the constraints of particular program and hardware products. 

We first provide the outline of data flows along the major activities within the 
DRMS system, as in Figure 5.1. Since a logical database design is a representation of 
reality, it will be helpful to understand the system, and further to plot the logical 
model. 



CASH / BUDGET TR 



budget allocation budget allocation 




MATERIAL SUPPLIES TP. 



request request 




EXPENDITURE 



MAINTENANCE 



receive receive 




Figure 5.1 Activity Chart of DRMS. 
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Next, we analyze in more detail the phenomena of the system, focusing on the 
user's information requirements described in Chapter 3. Throughout the analysis, we 
try to answer the questions like : 1) what are the prominent objects (entities) of the 
system?; 2) what aspects of reality are we trying to represent?; 3) what are the 
relationships between the entities? By answering these questions we can formulate a 
logical model of the DRMS as shown in Figure 5.2. This logical model provides the 
conceptual foundation for the following relational representation. 




Figure 5.2 Logical model of DRMS. 
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Entities of the resource management system are represented as squares and 
relationships shown by circles are named transaction, expenditures, operations, and 
inventory respectively in the DRMS. A relationship may exist between just two entities 
or among more entities depending on the activities involved. For example in the case of 
the EXPENDITURE relation, the expenditure activities are established when a unit 
uses any resources for certain operational purposes. 

C. FORMATION OF A RELATION 

A relation can be viewed conceptually as a two-dimensional table that has several 
properties. Based on the logical model previously defined, each object (entity) or 
relationship forms a relation, except some objects with a single value (attribute), which 
are is regarded as the unique characteristics in the military situation. 

Now, before representing those relations, in which all the resource activities are 
recorded and stored as input data for the purpose of future analysis, first let us explain 
some common attributes of relations. 

1. Attributes of relations 

A relation is a table which can be processed within the relational database 
system. When a resource is transacted or expended by the unit(s), this event should be 
recorded in the appropriate relations. 

The issue then becomes what kind of data to include as attributes and how to 
record them? These considerations are closely associated with the desired output 
information. 

Generally, each relation associated with resource activities should have the 
following attributes (contents): 

• Transaction number (TR#): a serial number given to each transaction activity 
according to its time sequential occurance. 

• Time: time period or date when the resource activities happen 

• Unit: the unit (division, regiment, etc.) which assumes the responsible 
accounting entity. In the case of transaction, units are divided into supplier and 
recipient. 

• Resource: the identified material that is transacted or expended. Materials are 
sub-classified into individual items within the seven asset groups. 

• Stock#: All the government supplied items are given numbers according to the 
class and characteristics. 

• Purpose: Every expenditure is classified as ordinary maintenance; command and 
staff activities; major mission accomplishment; troop welfare; investment; 
training and exercises, etc.. 
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• Amount: the number or volume transacted or expended resources. Since the 
different materials have different units of measurement, we need to decide a 
uniform rule for the basic unit of each resource-related input data, such as S, 
kg, gallon, unit, round, etc.. 

• Svalue: the money value of the resources transacted or expended. By 
introducing a standard price system, the whole Army (defense system) can apply 
identical price levels for each resource item. This is very convenient and helpful 
in maintaining consistent performance measurement and cost-effectiveness 
control of the unit. 

2. Representation of Relation 

An Army division has seven classes of floating assets by and large: (1) cash, 
(2) food, (3) petroleum, (4) ammunitions, (5) repair parts, (6) individual maintenance 
material, (7) troop maintenance material. Most of the resource management activities 
originate from the transaction and expenditures on those resources. Data collection of 
equipment operations and the determination of inventory level are also important 
aspects of the DRMS. To cover all activities of the Army division, many different 
relations will be designed to form a single data pool in the relational database. One of 
the most important considerations in designing the relations is the elimination of 
anomalies (insertion, deletion, update). The attributes comprising the key of each 
relation are displayed in capital letters. 
a. Common Entity data 

Resource, unit (supplier, recipient, expenditure unit), and equipment are the 
entities applied to every relation. Units and equipment, however, have only a single 
attribute and can be identified by unique code numbers (refer to Appendix A). 

Resources can be classified into two groups according to their usage 
characteristics: budget/cash, supplies material (weight material). So they are 
represented in different relations like Figures 5.3 and 5.4. 

(1) Budget relation. 



BUDGET# 


Exp. item# 


Amount 









Figure 5.3 BUDGET relation. 
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RESOURCE# 


Stock# 


Price 









Figure 5.4 RESOURCE relation. 
b. Transaction Data 

The transaction activities are divided into three parts according to their 
characteristics: (a) supplies request, (b) cash/budget transactions, (c) supplies 
(material/equipment) transactions. 

(1) Request relation. The REQUEST relation consists of five attributes 
(request number, time, resource code, requested/canceled amount) as shown in Figure 
5.5. 



REQUEST# 


Time 


Resource# 


Amount 











Figure 5.5 SUPPLIES-REQUEST relation. 

(2) Cash! budget transaction. Transaction data should be recorded for each 
occurrence of budget allocation and receipt/transfer of cash. The format for the 
CASH-TRANSACTION relation is shown in Figure 5.6. 



TR# 


Time 


Issuer 


Recipient 


Budget# 


Amount($) 















Figure 5.6 CASH-TRANSACTION relation. 

The attribute 'TR#' (transaction code) identifies three cases of 
transaction and is numbered in a time sequential manner. 'Issuer' indicates the higher 
level of unit (Corps, Army command) in the case of budget allocation or transfer of 
cash, while 'recipient' stands for the subordinate organizational unit or functional staff 
office when there is a transfer of cash. 'Budget code' is for the detailed budget item 
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from the chapter through subitems. 'Expense item code' assigns the specific item where 
the budget/cash should be expended. The detailed contents of the attribute are 
explained in Appendix A (coding system). 

(3) Supplies Transaction. Supplies transactions deal with the weight 
material, namely all the floating assets except cash. The relation shows all the supplies 
flow activities, such as receipt, issues, and return. As shown in Figure 5.7, the 
transaction of the weight material which moves in and out of the division can be 
represented with six attributes. 



TR# 


Time 


Supplier 


Recipient 


Resource# 


Amount 















Figure 5.7 SUPPLIES-FLOW relation, 
c. Expenditure Data 

Detailed data about resource expenditures are very informative in revealing 
what kind of and how much resources are used for what purpose. Since the lower level 
of units, such as company, are the major source of the actual data, the division plays 
the most important role in collecting the various operating data efficiently and in 
generating repons or desired analyses. 

In the previous chapter, we classified the resources into seven floating 
assets. They have different usage and characteristics, so it is rational to store the data 
separately in three different relations: cash, weight material, and repair parts. 

(1) Cash expenditure Relation. This relation includes all the resource 
activities supported by the cash. 



BUDGET# 


Unit 


Time 


Purpose 


Facility 


Equipment 


Amount 

















Figure 5.8 CASH-EXP relation. 
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An organizational unit or staff office records the related data when the 
cash is paid to the subordinate unit or the contractor. The attribute 'facility' or 
'equipment' is applicable when the cash is used to maintain or repair either object. 

(2) Material expenditure relation. This relation records expenditure 
activities of weight material without repair parts, namely five resource classes' 
expenditure. A new tuple is added periodically or at the time of a major event by 
summing the amount of consumption for each unit. 



RESOURCE# 


UNIT 


TIME 


PURPOSE 


EQUIPMENT 


Facility 


Amount 

















Figure 5.9 MATERIAL-EXP relation. 

(3) Repair parts Relation. Considering the unique characteristics of the 
maintenance activity (refer to Figure 5.1), the REPAIR-PARTS relation, although 
similar to MATERIAL-EXP, is prepared separately. For every occurrence of a 
maintenance job, the unit adds a new tuple to the relation in Figure 5.10 . Based on the 
cumulative records of repaired .or exchanged parts of the equipment, the unit can 
determine the average life (cost) of the equipment. 



RESOURCE# 


Unit 


TIME 


Recipient 


EQUIPMENT 


Purpose 


E/M 


Amount 



















Figure 5.10 REPAIR-PARTS relation. 
d . Operational data 

The other relations are mainly oriented to the transaction and expenditure 
activities. Data about the operational performance and the current status of the 
available resources must also be included. The OPERATIONS and INVENTORY 
relations are designed to account for these defaulted data. 

(1) Equipment operation relation. The operational performance data are 
needed to generate useful information about expense coefficients and performance 
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analysis. The attribute 'operation' holds the operational performance result of the 
equipment for a certain period. An example of input data is as follows: 1000 miles 
(maneuvering equipment); 500 hours (generator). 



EQUIPMENT 


Unit 


TIME 


PURPOSE 


Operation 













Figure 5.11 OPERATIONS relation. 

In some cases, the operational data can be obtained from the relations 
of other functional departments within the relational database system. 

(2) Inventory check-up relation. While the division maintains the data of 
transaction/expenditure activities, periodic check-up is recommended to prevent the 
erroneous estimation of the stock level. Coupled with the transaction and the separate 
expenditure relation, an inventory check-up relation, as in Figure 5.12, keeps track of 
the exact amount of resource available to the unit at a specific point of time. 



RESOURCE 


UNIT 


TIME 


Amount 











Figure 5.12 INVENTORY-CHECK-UP relation. 

Each organizational unit of the division is required to review its stock 
level periodically (quarterly or annually), and the data in the relation represents the on 
hand stock level at the time of physical counting. 

D. SQL MANIPULATION 

Data stored in a database are valuable only when they are retrieved to meet the 
user's information requirements through the data manipulation process. SQL is well 
known as a powerful and flexible data manipulation language and is becoming a 
standard for relational DBMS. Now we illustrate a set of SQL operations for three 
examples using simulated data for the purpose of illustration. 
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1. Case I: Information for Expense Coefficient 

The expense coefficient is used as the basis for estimating the standard cost in 
operating a piece of equipment. To produce a reliable expense coefficient, the 
regression method is commonly used. The required information includes any data 
influencing the total expense which can subsequently be used as possible variables of 
the regression equation. 

Here we take the example of a 1/4 ton jeep, as typical equipment applicable to 
all units. The first thing to do is to get the resource expenditure data and the 
operational data for certain operational conditions. We show the data manipulation 
via an actual SQL operation, given the data in Figure 5.13, Figure 5.14, Figure 5.15, 
and Figure 5.16. 



Resource# 


Unit 


Time 


Purpose 


Equipment 


Facility 


Amount 


1503 


3100 


870115 


31 


11010300 




48,000 


1503 


3300 


870115 


31 


11010300 




51,600 


1510 


4200 


870115 


31 


13010520 




76 


3301 


3100 


870115 


10 


31012010 




300 


3301 


3100 


870115 


20 


31012010 




610 


3301 


3100 


870115 


31 


31012010 




425 


3301 


3200 


870115 


10 


31012020 




240 


3301 


3200 


870115 


20 


31012020 




630 


3301 


3300 


870115 


10 


31012030 




230 


3301 


3300 


870115 


20 


31012030 




400 


3301 


3300 


870115 


31 


31012030 




280 


3301 


4100 


870115 


10 


31012040 




410 


3301 


4100 


870115 


20 


31012040 




950 


3301 


4200 


870115 


10 


31012050 




360 


3301 


4200 


870115 


20 


31012050 




475 


3301 


4200 


870115 


31 


31012050 




310 


3302 


4200 


870115 


31 


31050520 




430 


1503 


3200 


870130 


31 


11010300 




49,200 


1503 


4100 


870130 


31 


11011300 




32,000 


1510 


4100 


870130 


31 


13010510 




72 


3301 


3100 


870130 


10 


31012010 




350 


3301 


3100 


870130 


20 


31012010 




470 


3301 


3200 


870130 


10 


31012020 




260 


3301 


3200 


870130 


20 


31012020 




575 


3301 


3200 


870130 


31 


31012020 




450 


3301 


3300 


870130 


10 


31012030 




195 


3301 


3300 


870130 


20 


31012030 




420 


3301 


4100 


870130 


10 


31012040 




470 


3301 


4100 


870130 


20 


31012040 




1,110 


3301 


4100 


870130 


31 


31012040 




360 


3301 


4200 


870130 


10 


31012050 




390 


3301 


4200 


870130 


20 


31012050 




680 


3302 


4100 


870130 


31 


31050510 




520 



Figure 5.13 MATERIAL-EXP relation. 
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Resource# 


Unit 


Time 


Recipient 


Equipment 


Purpose 


E/M 


Amount 


1411 


3100 


870115 


3110 


11010300 


31 


I 


3 


3412 


3100 


870115 


3110 


31012010 


10 


I 


2 


3415 


6100 


870115 


3200 


31012020 


10 


II 


1 


3416 


3200 


870115 


3230 


31012020 


20 


I 


1 


3417 


4100 


870115 


4110 


31012040 


10 


I 


2 


3419 


4200 


870115 


4220 


32012050 


10 


I 


5 


3451 


6100 


870115 


4200 


31050520 


31 


II 


3 


1411 


3200 


870130 


3230 


11010300 


31 


I 


5 


1458 


0300 


870130 


4100 


13010510 


31 


III 


1 


3411 


3100 


870130 


3120 


31012010 


20 


I 


2 


3412 


3200 


870130 


3210 


31012020 


31 


I 


2 


3415 


3300 


870130 


3330 


31012030 


20 


I 


2 


3415 


4100 


870130 


4120 


31012040 


20 


I 


2 


3417 


4100 


870130 


4130 


31012040 


31 


I 


3 


3417 


4200 


871030 


4210 


31012050 


20 


I 


1 


3459 


6100 


870130 


4100 


31050510 


31 


II 


2 



Figure 5.14 REPAIR-PARTS relation. 



Equipment 


Unit 


Time 


Purpose 


Operation 


31012010 


3100 


870115 


10 


560 


31012010 


3100 


870115 


20 


1,300 


31012010 


3100 


870115 


31 


500 


31012020 


3200 


870115 


10 


310 


31102020 


3200 


870115 


20 


1,900 


31012030 


3300 


870115 


10 


210 


31012030 


3300 


870115 


20 


850 


31012030 


3300 


870115 


31 


300 


31012040 


4100 


870115 


10 


1,000 


31012040 


4100 


870115 


20 


2,700 


31012050 


4200 


870115 


10 


700 


31012050 


4200 


870115 


20 


1,500 


31012050 


4200 


870115 


31 


700 


31050520 


4200 


870115 


31 


450 


31012010 


3100 


870130 


10 


440 


31012010 


3100 


870130 


20 


1,700 


31012020 


3200 


870130 


10 


440 


31012020 


3200 


870130 


20 


1,600 


31012020 


3200 


870130 


31 


500 


31012030 


3300 


870130 


10 


290 


31012030 


3300 


870130 


20 


1,150 


31012040 


4100 


870130 


10 


1,200 


31012040 


4100 


870130 


20 


2,500 


31012040 


4100 


870130 


31 


600 


31012050 


4200 


870130 


10 


500 


31012050 


4200 


870130 


20 


1,300 


31050510 


4100 


870130 


31 


480 



Figure 5.15 OPERATIONS relation. 
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Resource# 


Stock# 


Price 


1411 


1-23-15 


10,000 


1458 


1-23-56 


220,000 


3301 


3-20-05 


3,000 


3411 


3-23-11 


75,000 


3412 


3-23-21 


100,000 


3415 


3-23-52 


115,000 


3416 


3-23-64 


75,000 


3417 


3-23-71 


37,000 


3419 


3-23-93 


70,000 


3451 


3-34-86 


150,000 


3459 


3-34-92 


123,000 



Figure 5.16 RESOURCE relation. 

In order to produce a table of data resource expenditures on 1/4 ton jeeps for 
different operational conditions, an SQL query block must be designed. This example 
requires a. typically simple query operation with SELECT, FROM, and WHERE 
working on 4 relations. Basically this query block is a composition of the relational 
algebra operations of projection and join under one restriction. In other words, 
relations MATERIAL-EXP and OPERATIONS are joined by attributes Equipment, 
Purpose, Time, and Unit whereas relations MATERIAL-EXP and RESOURCE are 
joined by attribute Resource#. A RESOURCE relation is provided to produce a unit 
money value for each resource expended. 

Given the relations described above, we formulate two separate query blocks 
to facilitate the query operation. Now we illustrate each procedure step by step to 
reach the final information. 

The first query block represents the projection and join operation over the 
MATERIAL-EXP and OPERATIONS relations as follows: 

SELECT MATERIAL-EXP. Equipment, MATERIAL-EXP. Resource#, 
MATERIAL-EXP. Purpose, SUM(Operation), SUM(Amount), 

FROM MATERIAL-EXP, OPERATIONS 

WHERE MATERIAL-EXP. Equipment IN (31012010, 31012020, 31012030, 
31012040, 31012050) 

AND MATERIAL-EXP. Equipment = OPERATIONS. Equipment 
AND MATERIAL-EXP. Purpose = OPERATIONS. Purpose 
AND MATERIAL-EXP. Time = OPERATIONS. Time 

AND MATERIAL-EXP. Unit = OPERATIONS. Unit 
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GROUP BY Equipment, Purpose, Time 
ORDER BY Equipment 

The relation, as in Figure 5.17, resulting from the query shows the amount of 
resource (3301; gasoline) used for equipment operations (maneuvering mileage) and 
three operational purposes. 



Equipment 


Resource 


i Purpose 


Operatior 


Amount 


31012010 


3301 


10 


1,000 


650 


31012010 


3301 


20 


3,000 


1,080 


31012010 


3301 


31 


500 


425 


31012020 


3301 


10 


700 


600 


31012020 


3301 


20 


3,500 


1,205 


31012020 


3301 


31 


500 


450 


31012030 


3301 


10 


500 


425 


31012030 


3301 


20 


2,000 


820 


31012030 


3301 


31 


300 


280 


31012040 


3301 


10 


2,200 


890 


31012040 


3301 


20 


5,200 


2,060 


31012040 


3301 


31 


700 


360 


31012050 


3301 


10 


1,200 


750 


31012050 


3301 


20 


2,800 


1,155 


31012050 


3301 


31 


600 


310 



Figure 5.17 MATERIAL EXPENDITURE ON 1/4 TON JEEP. 

The second query block is designed to produce data about the amount and 
Svalue of the repair-parts expenditures for each operational purpose, as follows: 
SELECT REPAIR-PARTS. Equipment, REPAIR-PARTS. Resource#, 
REPAIR-PARTS. Purpose, SUM(Operation), SUM(Amount), 
SUM(Amount*Price) 

FROM REPAIR-PARTS, OPERATIONS, RESOURCE 

WHERE REPAIR-PARTS. Equipment IN (31012010, 31012020, 31012030, 
31012040, 31012050) 

AND REPAIR-PARTS. Equipment = OPERATIONS. Equipment 
AND REPAIR-PARTS. Purpose = OPERATIONS. Purpose 
AND REPAIR-PARTS. Time = OPERATIONS. Time 
AND REPAIR-PARTS. Unit - OPERATIONS. Unit 
AND REPAIR-PARTS. Resource# = RESOURCE. Resource# 

GROUP BY Equipment, Resource, Purpose 
ORDER BY Equipment 
The output data is generated as in Figure 5.18 
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Equipment 


Resource 


Purpose 


Operation 


Amount 


$Value 


31012010 


3412 


10 


560 


2 


200,000 


31012010 


3411 


20 


1,700 


2 


150,000 


31012020 


3412 


31 


500 


2 


200,000 


31012020 


3415 


10 


310 


1 


115,000 


31012020 


3416 


20 


1,900 


1 


75,000 


31012030 


3415 


20 


1,150 


2 


230,000 


31012040 


3415 


20 


2,500 


2 


230,000 


31012040 


3417 


10 


1,000 


2 


74,000 


31012040 


3417 


31 


600 


3 


111,000 


31012050 


3417 


20 


700 


1 


37,000 


31012050 


3419 


10 


1,300 


5 


350,000 



Figure 5.18 REPAIR PARTS EXPENDITURE ON 1/4 TON JEEP. 

Finally, we want to combine the above two tables (Figure 5.17 and 5.18) to get the 
final information in a single table which explains all resource expenditures on the 1/4 
ton jeep according to operational purpose and performance with the S value for the 
repair parts. 

In order to do this, however, we need to restructure the design somewhat. In 
particular, we combine the two relations MATERIAL-EXP and REPAIR-PARTS into 
a single base relation as follows: 

PHYSICAL-EXP (Type, Resource#, Equipment, Time, Purpose, Unit, Amount, 
Facility, Recipient, E/M) 

Then we can create the tables MATERIAL-EXP and REPAIR-PARTS as views on 
the general base relation as follows: 

CREATE VIEW MATERIAL-EXP AS 

(SELECT Resource#, Unit, Time, Purpose, Equipment, Facility, Amount 
FROM PHYSICAL-EXP 
WHERE Type = 'ME' 

CREATE VIEW REPAIR-PARTS AS 

(SELECT Resource#, Unit, Time, Recipient, Equipment, Purpose, E/M, 

Amount 

FROM PHYSICAL EXP 
WHERE Type = 'RP') 

This allows us to use the SQL commands exactly as above but with the added 
flexibility of generating the overall expenditure table by substituting PHYSICAL-EXP 
for MATERIAL-EXP (or REPAIR-PARTS). This will yield the table in Figure 5.19. 
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Equipment 


Resource 


Purpose 


Operation 


Amount 


Amt*Price 


31012010 


3301 


10 


1,000 


650 


1,950,000 


31012010 


3301 


20 


3,000 


1,080 


3,240,000 


31012010 


3301 


31 


500 


425 


1,275,000 


31012010 


3412 


10 


560 


2 


200,000 


31012010 


3411 


20 


1,700 


2 


150,000 


31012020 


3301 


10 


700 


600 


1,800,000 


31012020 


3301 


20 


3,500 


1,205 


3,615,000 


31012020 


3301 


31 


500 


450 


1,350,000 


31012020 


3412 


31 


500 


2 


200,000 


31012020 


3415 


10 


310 


1 


115,000 


31012020 


3416 


20 


1,900 


1 


75,000 


31012030 


3301 


10 


500 


425 


1,275,000 


31012030 


3301 


20 


2,000 


820 


2,460,000 


31012030 


3301 


31 


300 


280 


840,000 


31012030 


3415 


20 


1,150 


2 


230,000 


31012040 


3301 


10 


2,200 


890 


2,670,000 


31012040 


3301 


20 


5,200 


2,060 


6,180,000 


31012040 


3301 


31 


700 


360 


1,080,000 


31012040 


3415 


20 


2,500 


2 


230,000 


31012040 


3417 


10 


1,000 


2 


74,000 


31012040 


3417 


31 


600 


3 


111,000 


31012050 


3301 


10 


1,200 


750 


2,250,000 


31012050 


3301 


20 


2,800 


1,155 


3,465,000 


31012050 


3301 


31 


600 


310 


930,000 


31012050 


3417 


20 


700 


1 


37,000 


31012050 


3419 


10 


1,300 


5 


350,000 



Figure 5.19 RESOURCE EXPENDITURE ON 1/4 TON JEEP. 

2. Case II: Resource expenditure result of an exercise 

Data about the resource expenditure of an exercise provides valuable 
information for budget allocation and for the estimation of minimum wartime resource 
requirements. Relational database systems can produce the required information with a 
simple query block. 

SELECT Resource#, Unit, SUM(Amount) 

FROM (Associated) RELATIONS 
WHERE Time = (a specific date or period) 

AND Purpose = Exercise code number 
By using the same data as in Case I, let us perform an SQL manipulation to 
determine the amount of resources expended in field exercise identified with Code 31, 
which occurred during the second half of January 1987: 

SELECT Resource#, Unit, SUM(Amount) 

FROM PHYSICAL-EXP 

WHERE Time = 870130 

AND Purpose = 31 
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GROUP BY Resource#, Unit 
ORDER BY Resource# 

The table resulting from this query is shown in Figure 5.20. Note that by 
using the PHYSICAL-EXP table in the query, we get both material and repair parts 
expenditures. If we had desired only material expenditures, for example, we could have 
generated that table simply by substituting MATERIAL-EXP for PHYSICAL-EXP in 
the above query. 



Resource# 


Unit 


Amount 


1411 


3200 


5 


1458 


4100 


1 


1503 


3200 


49,200 


1503 


4100 


32,000 


1510 


4100 


72 


3301 


3200 


450 


3301 


4100 


360 


3302 


4100 


520 


3412 


3200 


2 


3417 


4100 


3 


3459 


4100 


2 



Figure 5.20 Resource Expenditure in Field Exercise. 

We can display this output data in various formats, according to the desired 
usage of the information. In some cases we might need data only about the total 
amount of resource expenditure at the division level, while in other cases we might 
differentiate the amount for each organizational unit. The latter case is mainly used for 
the purpose of unit performance evaluation, comparing the expenditure amount with 
its performance results (mission accomplishment). The amount of the resource can 
also be also converted into a money value by using the 'price' attribute of RESOURCE 
relation for accounting purposes. 

3. Case III: Determination of the Inventory level 

The division performs a physical counting of the inventory level periodically 
and maintains its records for each resource of the unit. However, the current system, 
without the database facilities, encounters many difficulties in determining the accurate 
resource level available at a certain point of time. It relies upon many interrelated 
documents which takes a considerable amount of time. 
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However, with some simple relational database query operations, we can 
figure out the exact level of on-hand stock easily. As shown in the logical model 
previously introduced, the current stock level is determined from 3 sources: inventory 
check-up, expenditure records, and transaction results. 

Now we present an example SQL query which provides the desired 
information. For the purpose of representation, we suppose that we want to know the 
ammunition stock level of the 2nd Infantry Regiment at the beginning of February 
1987. In order to make the desired data manipulation, we need the SUPPLIES-FLOW 
and INVENTORY-CHECK-UP relations in addition to the expenditure data from the 
previous section. Figure 5.21 and Figure 5.22 provide the sample data for these 
relations. 



TR# 


Time 


Supplier 


Recipient 


Resource# 


Amount 


11401 


870105 


0410 


3100 


1505 


10,000 


11402 


870110 


0410 


3200 


1505 


10,000 


11403 


870115 


0410 


3300 


1505 


10,000 


21402 


870116 


3100 


6200 


1505 


20,000 


11405 


870120 


0410 


3200 


1503 


40,000 


11406 


870125 


6200 


4100 


1503 


25,000 


21406 


870129 


3200 


6200 


1503 


10,000 



Figure 5.21 SUPPLIES-FLOW relation. 



Resource 


Unit 


Time 


Amount 


1503 


3100 


860615 


15,000 


1503 


3200 


860615 


23,000 


1503 


3300 


860615 


18,000 


1503 


4100 


860615 


9,000 


1503 


4200 


860615 


8,600 


1503 


6200 


860615 


50,000 


1503 


3100 


870110 


25,000 


1503 


3200 


870110 


30,000 


1503 


3300 


870110 


21,000 


1503 


4100 


870110 


11,000 


1503 


4200 


870110 


9,000 


1503 


6200 


870110 


60,000 



Figure 5.22 INVENTORY-CHECK-UP relation. 
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Before getting into the SQL operation, let us explain the logic of the required 
query in the ordinary algebraic terms: 

Current Inventory Level = {(Previous Inventory Level) + (Received Material)} - 
{(Expended Material) + (Returned Material)} 

This information requires four separate query blocks as follows: 

(1) Previous Inventory Level: 

SELECT Amount 

FROM INVENTORY-CHECK-UP 
WHERE Time = 870110 
AND Unit = 3200 
AND Resource# = 1503 

(2) Received Material: 

SELECT SUM(Amount) 

FROM SUPPLIES-FLOW 
WHERE Resource# = 1503 
AND Recipient = 3200 
AND Time BETWEEN 870110 AND 870131 

(3) Expended Material: 

SELECT SUM(Amount) 

FROM MATERIAL-EXP 
WHERE Resource# = 1503 
AND Unit = 3200 

AND Time BETWEEN 870110 AND 870131 

(4) Returned Material: 

SELECT SUM(Amount) 

FROM SUPPLIES-FLOW 
WHERE Resource# = 1503 
AND Supplier = 3200 
AND Time BETWEEN 870110 AND 870131 
From the above queries we get the resulting amounts of 30,000, 40,000, 
10,000, and 49,200 respectively. By using the report generator capability of the 
database system, we can generate a single value of present stock level as shown in 
Figure 5.23. 
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Resource# 


Unit 


Amount 


1503 


3200 


10,800 



Figure 5.23 CURRENT INVENTORY LEVEL. 

This kind of query procedure is usually supported by the report generator 
capability of the database system. Apart from the ad hoc queries, some typical 
information required frequently can be generated easily with embedded query 
procedures. 

E. DATA BASE ADMINISTRATION 

So far we have discussed the application capabilities of a relational database 
management system. The database system makes possible flexible application of the 
shared data by various queries. Now we need to pay attention to another aspect of the 
DRMS: How can we administer the database effectively to satisfy the information 
requirements without interruption? Given the complex and multifaceted activities of a 
resource management system, this issue deserves careful consideration. 

1. Data Entry 

The procedure of data entry should be strictly controlled to insure accuracy 
and consistency of the data. In order to accomplish this, a position responsible for data 
entry can be assigned under the director of the resource management department. The 
frequency of data entry should be divided into two categories: periodic and occasional. 
The resources expended in the unit's ordinary activities are recorded by the total 
amount during the period (weekly or monthly). Expenditures on special events, such 
as field exercise or annual combined operation, are input at the time of resource 
activity. These two types of data entry are recommended to facilitate future data 
manipulation associated with a specific event. 

2. Database Maintenance 

In the course of data base implementation, some actions should be taken to 
insure the DBMS is serving the users as intended. These include security procedures 
and database performance monitoring. Unauthorized access and modification of the 
database can cause serious problems. Especially since the DRMS is dealing with 
military materials, the disclosure of data about key materials related to combat 
readiness must be protected. The division needs to install security features carefully 
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designed to minimize unnecessary overclassified materials. In addition, backup 
procedures are required to protect against hardware failure or disk loss. 

The data base must be able to provide the user with a high degree of 
continuous performance. This performance is based on matching the unit's information 
requirements with current technology. The database administrator is expected to 
maintain a systems performance balance among the hardware, software, and 
applications. If users of the division's DBMS complain about the process time, access 
procedure, or the application capabilities of the system, mechanisms must be available 
for the possible resolution of the matter. 

3. Data Integrity 

Counteracting the advantages of the data base environment is the increased 
threat resulting from centralized data. Since many applications are performed with the 
same data, improper editing or inconsistent data handling among the on-line users 
makes transaction auditing difficult. Furthermore since other applications may 
continue to access incorrect data, the problem can give rise to a complicated situation. 

In order to preserve the database integrity effectively, standards, testing, 
procedures, and policies should be enforced by responsible authorities [Ref. 11: p. 142] 
Those procedures enable the DBMS personnel to maintain integrity, detect the 
problems, and correct them more easily. 

4. Advent of a New Position: DBA 

The above functions introduced by the database system imply the necessity for 
new authorities to take comprehensive responsibility for the data base. Previously 
individual data was controlled by individual departments, but the integration of data 
shared among groups requires coordination and centralized control among the users. 

Nowadays the position of data base administrator (DBA) is common in 
organizations with database practices. A DBA can be created as a new staff officer in 
the division. Considering the current organizational structure of the Army division, the 
DBA may be positioned as in Figure 5.24. 

The operation of the DRMS ranges over all the general/functional staffs 
(departments), however the DBA must control and coordinate the activity of data 
entry and maintenance. Even though each department may have its own data 
administrator who is responsible for maintaining the department-related data, the DBA 
assumes the higher and final responsibility about the administrative and technical 
tasks. A DBA can be placed under the EDP manager supervised by the G-5 (Resource 
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Figure 5.24 DBA of the Army division. 

Management Department), because the DBMS is a part of EDP (computer center) 
group. 

F. SUMMARY 

The intent of this chapter is to show how a relational database helps the DRMS 
meet its complicated and diverse information requirements. 

This chapter first explained the DRMS environmental issues for which the DB 
system is supposed to operate. Since the DBMS is a new system compared to the 
current DRMS file system, we proposed four major factors be developed in order to 
exploit the advantage of the relational DB system; 

• Detailed coding system 

• Stand price system 

• Measurement unit 

• Reporting document format 

Following the logical model of the DRMS system, a relational schema was 
designed similar to an input record format in a file system environment. Designing a 
relational schema requires elaborate efforts to eliminate various anomalies and to 
facilitate data manipulation. We created 10 relations to cover all information 
requirements identified in Chapter III. 
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SQL operations were illustrated to show the flexible and powerful data 
manipulation application capability of the relational DBMS. The three sample cases in 
this chapter demonstrate only a part of the full capability of the system. Once the 
relational DBMS is established, the user can produce many kinds of information with 
SQL query operations. The SQL data manipulation language, though relatively simple 
to use, proves to be a very flexible and powerful tool. 

Finally, administrative aspects of the DBMS were briefly discussed: data entry; 
database maintenance; data integrity. The introduction of DBMS requires 
corresponding change in the division's information requirements environment. A new 
position of DBA group was recommended to be responsible for the technical and 
administrative aspects of the data base. 
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VI. DATA ANALYSIS AND APPLICATIONS 



The objective of defense resource management system (DRMS) is to help 
commanding officers manage and control the total resources of their units effectively 
and efficiently, and to enable them to make resonable decisions on the basis of timely, 
accurate, and relevant information. 

To accomplish this objective, up to this point, we have reestablished the 
information requirements for DRMS and built a suitable database management system 
in order to obtain meaningful output data easily. 

Some information can be directly obtained from the output data. However, to get 
more accurate and relevant information we must apply some analytical techniques or 
models. Therefore, -in this chapter, we introduce some analytical techniques and models 
for decision making that can be applicable to the ROK Army division level. 



A. REGRESSION MODEL FOR EXPENSE COEFFICIENT 

Regression analysis is powerful method of estimation and the most commonly 
used casual approach to forecasting. It is quite flexible and can include any number of 
factors in the forecasting models. 

Many managerial decisions require predictions or forecasts of future events. 
These predictions frequently are based on historically observed relationships between 
variables. These predictions could be made by using regression analysis. This technique 
is widely used to determine the statistical relationship between two (or more) variables 
and make predictions of one variables on the basis of the other(s). 

1. Simple Linear Regression 

In a simple linear regression analysis we attempt to develop a linear model 
from which the values of a dependent (i.e., response) variable cab be predicted based 
on particular values of a single independent variable. To develop the model a sample of 
N independent pairs of observations (Xj Yj), (X2 Y2), ..., (X n Y n ) are obtained, 
where Xj represents the ith value of the independent or predictor variable X and where 
Yj represents the corresponding response - that is, the ith value of the dependent 
variable Y. 
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To study the possible underlying relationship between X and Y, the n 

% 

individual pairs of observations can be plotted on a two-dimensional graph called a 
scatter diagram. The dependent variable Y is plotted on the vertical axis, while the 
independent variable X is plotted on the horizontal axis. The scatter diagram aids the 
researcher in selecting an appropriate regression models. By examining the plotted 
sample points, the researcher attempts to project the underlying mathematical 
relationship that may exist between X and Y. 

In a simple regression model wherein there is but one predictor variable X, 
this functional relationship can be expressed as 



where any observed value Yj in the population would be a function of the true 
mathematical model f^Xj) plus some residual £•. The £j term represents scatter above 
and below the regression equation. 

If the scatter diagram indicates a possible linear relationship between X and 
Y, the population regression model (6.1) can be re-expressed as 



where the two unknown parameters Pq and Pj are necessary for determining a straight 
line. Pq is the true intercept, a constant factor in the regression model representing the 
expected or fitted value of Y when X = 0. Pj is the true slope; it represents the 
amount that Y changes (either positively or negatively) per unit change in X. 

Since we do not have access to the entire population, we cannot compute the 
parameters Pq and Pj and obtain the population regression model. The objective then 
becomes one of obtaining estimates bQ (for Pq) and bj (for Pj) from the sample. 
Usually this is accomplished by employing the method of least squares. With this 
method the statistics bQ and bj are computed from the sample in such a manner that 
the best possible fit within the constraints of the squares model is achieved. That is, w r e 
obtain the linear regression equation 



Y - KXj) + £j 



(eqn 6.1) 



Yj - P 0 + Pl X i + £ i 



(eqn 6.2) 




(eqn 6.3) 



such that £ (Yj - Y-) = £ £^i is minimized. 
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2. Multiple Regression Model . 

In multiple regression at least two independent variables are used to predict 
the value of a dependent variable. The general form of multiple regression is 

Y = a + bjXj + b 2 X 2 + ... + b R X k 

The technique for estimating the parameters of the regression equation are similar to 
those used for simple regressions. A multiple regression model is much more 
complicated to use than a simple regression model. Generally speaking, the 
assumptions about the statistical form of the data and the procedures used for 
assessing the reliability of the estimates are extensions of those associated with simple 
linear regression. 

Estimates of the intercept and regression coefficients are obtained from a set 
of normal equations, the same as for simple regression, although the normal equations 
become more complicated and laborious to solve as the number of independent 
variables increases. Fortunately, computer package for multiple ression model is 
developed and we can easily get regression equation from computer package. 

3. Application of Regression Models 

Making a budget for the petroleum or repair parts of a specific model of 
vehicle, we usually confront some problems; how we should determine the criteria 
(petroleum consumption ratio per kilometer, repair part consumption ratio per 
kilometer) for operating the vehicle by 1 kilometer, and how we can determine the fixed 
amount of their consumption which are not related with the operation of the vehicle. 
Furthermore, we should take into consideration the activity under given conditions: 

• Logistic transportation and administration activity (LOG & ADM) 

• Training and military operation activity (TRN & OPT) 

• Commanding and staffing activity (CMD & STF) 

Different criteria determined depending upon the activities and road conditions are 
more relevant and accurate than one simple criterion obtained by simple calculation 
that is used in the current DRMS system. 

Assuming that there are 5 same model jeeps in the organizational unit, let's 
consider two kinds of the expense collecting data format for 5 jeeps. One format as 
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shown in Table 6 is now utilized in the current DRMS system. With this format we 
can get 0.465 l j km by dividing the total amount of petroleum (11,480 ltr) by total 
operating distance (24,700km). 



TABLE 6 

CURRENT DATA COLLECTING FORMAT 



Jeep No. 


Petroleum 

(ltr) 


Repair parts 
Expense ( $ ) 


Operational 
Distance( km) 


1 


2,155 


350,000 


4,500 


2 


2. 255 


390,000 


4,700 


3 


1,545 


230,000 


2,800 


4 


3,310 


415,000 


8,100 


5 


2,215 


387,000 


4,600 


Total 


11,480 


1,772,000 


24,700 



On the other hand, if we apply simple regression model with the same data, 
we can easily obtain a regression equation as follows: 

Petroleum consumption per km = 671 4- 0.329 x Distance(km). 

The result obtained from simple regression model is more accurate and relevant than 
one obtained by the simple division method. Allocating the petroleum for 10,000 km of 
operation, we must allocate the petroleum to the organizational unit by 4,650 ltr., if we 
use the criterion obtained from the simple division method. However, if we use the 
criterion obtained from simple regression model, we can allocate petroleum to the 
organizational unit by the only 3,9611tr. (671 + 0.329 x 10,000km). In the simple 
regression equation, the number 671 means the fixed consumption amount occured not 
related to the operating activity. 
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The other data collecting format created in the new DRMS as shown in Table 
7 is well improved one for multiple regression model. 



TABLE 7 

NEW DATA COLLECTING FORMAT 



Jeep 

No. 


Petroleum 
used 
(Itr. ) 


Operational Distance (km) 


LOG & ADM 


TRN & OPT 


CMD & STF 


1 


2,155 


1,000 


500 


3,000 


2 


2,255 


700 


500 


3,500 


3 


1,545 


500 


300 


2,000 


4 


3,310 


2,200 


700 


5,200 


5 


2,215 


1,200 


600 


2,800 


TOT 


11,480 


5,600 


2,600 


16,500 



We can compute the expense coefficient of each activity from data retained in the new 
format by using computer-aided multiple regression model. We can easily obtain the 
multiple regression equation by using computer package (MINTTAB) as follows: 

Y = 520 + 0.214Xj + 0.85X 2 + 0.331X 3 
Y : Petroleum consumption amount 

Xj : Distance for logistic transportation 
and administration activity 

X 2 : Distance for training and military activity 
X 3 : Distance for commanding and staffing activity 
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In this multiple regression equation, regression coefficients (0.214, 0.85, and 
0.331) contain very useful information. They represent the consumption coefficients of 
each activity. If we get these coefficients, we can forecast the needs of petroleum for 
certain level of activities with more accuracy and relevance. 

For example, if 50,000 km is for logistic and administration activity, 20,000 km 
is for training and military operation activity, 30,000 km for commanding and staffing 
activity, then the total amount of petroleum needed in those activities (38,150 ltr.) can 
be obtained from the above multiple regression equation (520 + 0.214x50,000 + 
0.85x20,000 + 0.331x30,000). 

In conclusion, simple regression model is better than simple division method, 
and multiple regression model is the best of the three methods in providing the criteria 
and equation that indicate influential elements for activities. Therefore, the first data 
collecting format should be convened to the second format for the new system with a 
view to obtain more accurate and meaningful information. 



B. INPUT-OUTPUT ANALYSIS FOR TOTAL COST 
1. General 

In this section, we discuss how forecasts can be made using an input-output 
model. 5 The procedure is presented both in matrix algebra and in words. The 
theoretical discussion is integrated with a numerical example. 

Input-output analysis examines the interrelations existing between 
components of a system. It does this by specifically accounting for the resource flows 
that bind the various components of the system into an interdependent whole. The first 
step in using input-output analysis is to divide the components of the system being 
modeled into "sectors". A sector represents one organization or function. In the models 
of the economy, a whole industry - such as steel - becomes one sector. In our model of 
the ROK Army division, sectors represent functions such as Ground Forces and Army 
Aviation Unit. 

These sectors are, in turn, divided into two groups: those that support other 
sectors and those that don't. Sectors that support other sectors produce goods and 
services and, in turn, consume goods and services; such sectors are called processors or 

5 Our procedure describes a static, open model. A static model forecasts each year 
independently of other years (that is, it does not allow for the dynamic interplay of one 
year on another). An open model assumes that the output of some activities (called 
final users) are not measured by the model. 
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support sectors. Those that don't support others but who do consume the output of 
the processors, consisting mainly of the operating forces, are called final users: final in 
the sense that they are the final step in the system. 

The resource flows that bind the system together are captured by measuring 
each sector's output provided to other support sectors and to final users (operating 
forces). These output measures, or workload indicators, relate changes in the final users 
to changes in the workloads and the resources consumed by the support sector. It is 
not necessary that these output measures be actual output. In the work described later, 
we utilized proxy variables for our output measures. Proxy variables are data which do 
not directly measure the workload of the support activity but which are assumed to 
vary roughly in proportion to a direct measure. For example, the actual output of 
recruit training is trained recruits. Our proxy variable is the number of Army division 
enlisted men in each sector. The rationale is that on the average the number of trained 
recruits required by each sector will vary in proportion to the number of men in that 
sector. 

This workload information is then organized into a matrix (called the 
transactions matrix) which has one row for each processor and as many columns as 
there are processors and final users. Each row represents the output of that support 
sector and shows how that sector's output is allocated to each of the consuming 
sectors, including itself. One sector's output becomes another sector's input so that 
each entry in a row is an input into the sector represented by the column. Thus, and 
this is the unique feature of this matrix, each element in the matrix is simultaneously 
an output of the sector represented by the row and an input to the sector represented 
by the column. (The name input-output comes from this layout.) In addition, all 
sectors, both processors and final users, need inputs not only from other sectors within 
the system, but also inputs from outside the system, such as labor and equipment. 
These primary inputs can be measured in any appropriate unit and are added to the 
above relationships by expanding the matrix to include more row’s representing the 
additional inputs. 

To illustrate the use of input-output analysis, we have constructed an example 
utilizing sample data for the ROK Army division level for fiscal year 1987. Table 8 
shows the two processors and tw r o final user sectors, their abbreviations used in later 
tables, the proxy variables for the support sectors, and the primary inputs for this 
example; Table 9 is the Transaction Matrix. The rows of the upper quadrants of the 
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Transaction Matrix represent the flow of support from support sectors to both support 
sectors and final users. The columns of the lower left quadrant are the resources that 
are inputted to the support sectors for them to generate their total outputs. In this 
case, the Base Operating Support sector needs 10 units of MP and 230 units of O&M 
to produce its total output of 60 units ( 10 + 10 + 20 4- 20 = 60 ). 



TABLE 8 

SECTORS AND PROXY VARIABLES USED IN SAMPLE PROBLEM 




Support Sectors 


Proxy Variables 


1. 


Base operating support 
f BOS ) 


Military pay (MP), 
Operations & 

maintenance (O&M) 


2. 


Logistics (LOG) 


Operations & 

maintenance (O&M) 




Final Users Sectors 


Primary Inputs 


1. 

2. 


Ground Forces ( GF ) 
Army Aviation UNit ( AAU) 


1. Military personnel 

( BP ) 

2. Operations & 
maintenance (O&M) 



The Transaction Matrix can be functionally divided into four quadrants as 
shown in Table 10. The rows of the U and V matrices represent the flow of support 
from the processors to both processors and final users. The columns of W and Z are 
the inputs to each sector from outside. Assuming there are m processors, n final users 
and k resource inputs, U is mXm, V is mXn, W is kXm and Z is kXn. In terms of table 
9, the U matrix is a 2 x 2 square matrix, V is a 2 x 2 matrix, W is a 2 x 2 matrix of 
resource resource inputs, and Z is a 2 x 2 matrix of resource inputs for the final users. 

This matrix of inputs and outputs in either dollars or units of real output is 
just a form of double entry bookkeeping. The usefulness of input-output analysis is 
that this matrix can be transformed into other matrices which can be manipulated to 
show structural interdependence and to predict the impact on support of force changes. 
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TABLE 9 

TRANSACTION MATRIX 





Processors 


Final User 


BOS 


LOG 


GF 


AAU 


BOS 


10 


10 


20 


20 


LOG 


40 


10 


20 


30 


MP 


10 


10 


20 


20 


O&M 


230 


260 


500 


600 





TABLE 10 


TRANSACTION MATRIX DIVIDED INTO FOUR QUADRANTS 




m columns 


n columns 


m rows 


U 


V 


k rows 


W 


Z 
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2. Transforming Step 

Several steps are involved in transforming the subdivided Transactions Matrix 
into a predicting device. 

a. Step 1. 

In step 1, each row of U and V is summed to create a column vector, X, of 
total output. 

m n 

L U - + £ V- = X- 
ij lj i 

j-1 

i = l,...,m 



In this example of Table 9, Xj = 60. 

b. Step 2. 

Each row of V is summed to create a column vector, Y, representing that 
part of total output being consumed by the final users. 



£ V” = Yj i = 1 m 

j-1 



In this example, Y is: 



40 

50 



c. Step 3. 

Each element of the jth column of U is divided by the jth element of X to 
create the mXm matrix A. 



u ii 



X; 




i = l,...,m 
j = l,...,m 
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Step 3 converts the U matrix, which contains gross data into a matrix of proportional 
coefficients, commonly called the A matrix. The A matrix is a square matrix with as 
many rows and columns as there are processors. In words, A is found by first 
summing across each row; this sum gives the total output of that sector. Then each 
element in the corresponding column of U is divided by that total. The result, for each 
support sector, is the number of units of inputs required from each of the sectors 
including itself for each unit of its output. 

For example, column 1 of U from table 9 is: 

10 

40 

Each element is divided by = 60. These results form column 1 of A which is: 

10/ 60 - 0.1667 
40 / 60 = 0.6667 

Table 11 shows the A matrix for our example. The entries in Table 11 are interpreted 
as follows: 0.6667 (at column 1, row 2) means that for every unit of BOS output, LOG 
must supply 0.6667 of a unit of its output. Our model is built upon these proportional 
relationships. 



TABLE 11 

THIS IS THE (A) MATRIX. 





BOS 


LOG 


BOS 


0. 1667 


0. lOOO 


LOG 


0. 6667 


0. 1000 
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d. Step 4. 

The matrix is subtracted from the identity matrix and then inverted. 6 See 
Table 12 for the inverse in our example. This inverse matrix (1 - A)'^ is our forecasting 
tool. The logic behind its derivation and use can be understood by considering the 
following series of equation: 

X = AX + Y 

X - AX = Y 
(I - A)X = Y 

X = (I - A)* ! Y 



e. Step 4. 

As before, X is a column vector representing total output from the support 
establishment and Y is a column vector representing that part of total output being 
consumed by the final users. AX is column vector representing output consumed by 
processors. 

The (I - A)"* matrix has a very important property; each of its elements r^- 
shows the total support (as measured by the proxy variables) sector i must provide to 
enable sector j to provide one unit of its output. 7 

The usefulness of the (I - A)'^ matrix is that once it is developed for one 
set of demands it can be multiplied times a new level of demands by final users (e.g., a 
new force level), denoted by Y', to obtain an estimate of the total output requirements 
from each of the support sectors. Given Y', the required output, X', is estimated by: 

X' = (I - A y l Y' 
where 
m 

Y'i = - V'jj i = l,...,m 

j=l 



6 The inverse of a matrix has the same role in matrix algebra that the reciprocal 
plays in regular numbers. That is if AX = Y, then X = 1/A or A'*Y. The inverse of a 
matrix is denoted by the same symbol -1. 

7 The inverse matrix (I - A)*^ = I + A + A^ + A^ + ... The expression I + A 
represents direct support. Each round of support on support is represented by A n The 
inverse represents the sum from n = 0 to n = °o of A n 
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TABLE 12 

THIS IS THE (I - A) INVERSE MATRIX. 



0. 1667 0. 1000 

0. 6667 0. 1000 



0. 1667 


0. 1000 


0. 6667 


0. 1000 


0. 8333 


- 0. 10000 


0. 6667 


0. 90000 


0. 8333 


- 0. 1000 


0. 6667 


0. 9000 



(0. 8333)(0. 9) - (- 0. 6667 ) ( - 0.1) 



1.3171 0.1463 

0.9756 1.2195 



For example, let's calculate the required total support (X') for next year with a doubled 
Ground Forces and 5 time Army Aviation Units. We can obtain the required total 
support of BOS; 212 and the required total output of LOG; 369 as shown in Table 13. 

The inverse matrix, (I - A)"*’ can also be used to estimate the marginal 
impact of a force change. Defining the force change as A Y', then the marginal impact, 
A X', is computed by: 



A X' = (I -A)' 1 A Y* 



/. Step 5. 

The resources required to produce the new output, X', must now be 
calculated. We assume that all resource requirements vary proportionately to output. 
Our resource estimates are arrived at in the following way: 
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TABLE 13 



CALCULATION OF THE REQUIRED OUTPUT (X') 



20x2 + 


20x5 


140 


20x2 + 


30x5 


190 


1. 3171 


0. 1463 


140 


0. 9756 


1. 2195 


190 


212 






369 







Each element in the jth column of W is divided by the jth element of X: 




Xj 



B; 



i = l,...,k 
j = 1 m 



In our example, row 1 of W from Table 9 is: 



BOS LOG 
MP | 10 10 | 



First element is divided by Xj = 60 and second element is divided by X 2 = 100. These 
results form row 1 of B which is: 

110 / 60 10/ 100 1 = |0.1667 0.1000 | 



99 



The new W ( = W') is calculated by multiplying each element in the jth column of B by 
the jth element of X': 




B U x 'j 



i l,...,k 
j = l,...,m 



In the example, W' is calculated as follows: 



| 212 | 

W' - | 0.1667 0.1000 1 | | 

|369| 



= 72.3 



72.3 indicates the number of variable support personnel needed next year. 

The matrix W' contains the resource estimates for each support sector for 
forces contained in Y'. The matrix can contain as much detail about resources as 
desired. Each desired element becomes a row in B. 

The inverse matrix can also be used to allocate support resources to forces 
(final users). This is done by calculating shadow prices (which can be defined as the 
cost of all resources used, including those used indirectly, to produce each unit of 
support output) and multiplying these shadow prices times the units of support output 
used by each final user. 

C. OPTIMAL ALLOCATION OF REPAIR PARTS 

The operational availability of equipment is the most important criterion of all 
the concepts which have developed until now for measuring the material readiness. It is 
an index of system readiness in a mission environment which combines reliability, 
maintainability and supportability and probability that an item can perform its 
intended function when called upon. 

Operational availability of field equipment is heavily depended upon the 
maintainability. A certain level of repair parts must be secured and maintained to meet 
local needs and keep the desired level of maintainability. 
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In this section, we want to deal with a hypothetical case in order to determine 
the accurate repair part level. 

1. Background 

The ROK Army division aircraft are supported by a large inventory of spare 
parts that are kept readily available to replace components that fail on the aircraft. 
Many of the failed components are then taken to local repair activities and fixed. The 
level of inventory kept at the local activity is directly related to the frequency of failure 
and the length of time it takes to repair a failed component once it does fail. 

2. Data 

In order to accurately assess local needs, maintenance data is retained for each 
component that is repaired locally as shown in Table 14. The data layout provides 
character data, the failure dates, and the repair dates. 







TABLE 14 






MAINTENANCE DATA LAYOUT 


a. 


Item 


identification 


data 




1) 


national stock 


number 




2) 


component name 






3) 


application 






4) 


unit price 




b. 


Item 


failure date 






1) 


description 






2) 


failure date 




c. 


Item 


repair date 






1) 


description 






2) 


repair date 





For this case analysis, we are concerned with only two of the many data 
elements retained: the failure date and the repair date. Dates are maintained in the data 
file as Julian Dates. Julian dates are four digit numbers that represent the last digit of 
the year and the numeric order of the day within the year. The following examples may 
help to make this clear: 
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Date 



Julian date 



01 


January 


1986 


6001 


02 


January 


1986 


6002 


31 


January 


1986 


6031 


01 


February 


1986 


6032 


25 


October 


1986 


6298 


31 


December 


1986 


6365 


01 


January 


1987 


7001 



Data collected using Julian dates are much simpler to manipulate than using 
day/month/year. 

The data set used actually in this case are listed in Table 15 as Julian dates. 



TABLE 15 

MAINTENANCE DATA USED IN THE CASE 



Failure Date 



6304 

6323 

6314 

6316 

6307 

6302 

6321 

6321 

6329 

6312 



Repair Date 



6310 

6325 

6315 

6322 

6312 

6307 

6325 

6321 

6333 

6318 



Failure Date 



6316 

6325 

6302 

6302 
6316 
6321 
6301 

6312 

6303 

6313 



Repair Date 



6317 

6328 

6307 

6305 
6317 
6322 
6303 
6313 

6306 
6319 



3. Methodology 

To determine the accurate inventory level, however, we are not concerned with 
the date that a component fails, but rather with the length of time that it is in NOt 
Ready For Issue (NRFI) status - the length of time between failure and repair. To get 



102 



a reasonable idea of the typical repair time, it is also necessary to accumulate data over 
a lengthy period of time, then calculate the Average Repair Turn Around Time (TAT). 
This allows us to develop a proper inventory at a reasonable cost. 

4. Procedure 

Using the APL programming language, we can determine the accurate 
inventory level with the following procedures: 

1. Finding FIRST FAILURE DATE (FFD) 

2. Finding LAST FAILURE DATE (LFD) 

3. Calculating ANALYSIS PERIOD (AP). 

• AP = LED - FFD + 1 

4. Determining TOTAL FAILURES (TF). 

5. Calculating AVERAGE DAILY FAILURES (ADF). 

• ADF = TF/AP 

6. Calculating MINIMUM, MAXIMUM, AND AVERAGE TURN AROUND 

TIME (TAT). 

• TAT = Repair date - Failure date + 1 

7. Calculating AVERAGE NUMBER IN REPAIR (RBAR). 

• RBAR = ADF x average TAT 

8. Computing POISSON ALLOWANCE. 

• Using RBAR as the parameter of a Poisson distribution, print a table that 
shows N and the CDF of the distribution P(X < = N). The meaning of 
this table is that if N components are stocked (in a system without repair 
capacity constraints), they will provide protection from stockout at a level 
%. 

5. Solution 

Using a simple APL function, we performed simple calculations on the input 
data and output the results as shown in Table 16. All the APL program used in this 
case and its solution are described in detail in Appendix C. 

In the Table 16, N indicates the number of components which should be 
stocked to provide protection from stockout at the protection level. P(X < = N) 
represents the probability that at most N components are needed. The PROTECTION 
LEVEL stands for the level at which they will provide protection from stockout if N 
components are stocked. 

To maintain the 100 % protection level, we must secure at least 12 
components in this case. If we carry more than 12 components, however, we must 
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TABLE 16 

RESULTS OF ANALYSIS 



******* DATA ANALYSIS ******* 



FIRST FAILURE DATE 
LAST FAILURE DATE 
ANALYSIS PERIOD 

TOTAL FAILURE 

AZSSAQE QAI&Z SAIRURES 

TURN AROUND TIME 

MINIMUM 
MAXIMUM 
AVER ACE 



6301 iULIAN DATES 

6329 

29 DAYS 

20 UNITS 

0.6897 UNITS / DAY 



1 DAY 

7 DAYS 

4.25 DAYS 



MEAN DAILY NUMBER IN REPAIR 



2.931 UNITS 



******* RESULTS OF ANALYSIS ******* 

IQLS.S.QE distriution table 

N P(XSN) PROTECTION LEVEL 



0 


0.05334 


5.334 


1 


0.2097 


20.97 


2 


0.4388 


43.88 


3 


0.6627 


66.27 


4 


0.8267 


82.67 


5 


0.9229 


92.29 


6 


0.9698 


96.98 


7 


0.9895 


98.95 


8 


0.9967 


99.67 


9 


0.9991 


99.91 


10 


0.9998 


99.93 


11 


0.9999 


99.99 


12 


1 


100 



accrue additional component costs for keeping the same protection level. Therefore, we 
should minimize the sum of the component costs and carrying costs by determining the 
accurate component level. 



k. 
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This analysis can help a resource manager to allocate the number of repair 
parts which should be stocked to provide protection from stockout at a certain 
protection level to the organizational unit. 

D. SUMMARY 

MIS developed in response to the needs of management for accurate, timely, and 
meaningful data for planning, analyzing, and controlling the organization's activities. 
Within recent years there has been increasing emphasis placed on helping managers 
make decisions on the basis of good information. As a result, the decision support 
model has become an essential subsystem within the framework of MIS. 

If a suitable database management system (DBMS) is available, then the decision 
support model can provide nonroutine information through an ad hoc query facility of 
the DBMS and sophisticated optimizing techniques and statistical packages can be 
used to analyze available data and provide feedback capabilities to management. 

The implementation of a decision support model requires sophisticated 
mathematical modeling techniques (e.g., linear programming and statistical 
forecasting), simulation methods, and high-powered computer support. Recent 
improvements in technology have made possible the implementation of such models in 
the U.S. Armed Forces. 

However, the automated data processing (ADP) technology in the ROK Army is 
at a primitive stage. To meet the increasing needs of information for decision making, 
various decision support models should be developed in the ROK Army division level. 
Those decision support models help a commanding officer make key decisions and 
thereby improve the effectiveness of the commanding officer's problem-solving process. 

In order to encourage the ROK Army division to develop various decision 
support models for reasonable decision making, we reestablished the information 
requirements and built a suitable database in the previous chapters. 

In this chapter, we showed three data analysis techniques (regression model, total 
cost model, and component allocating model), as examples for applications, using data 
obtained from Chapter V. These data analysis models are usually used for forecasting. 
Forecasting is an important aid in effective and efficient planning, programming and 
budgeting and it is an integral part of the decision-making activities of management. A 
large number of forecasting methods are available to management today. The 
widespread introduction of computers has made programs readily available for all 
quantitative forecasting techniques. 
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To be a leader in military management area, the ROK Army should reevaluate its 
current situation, try to assimilate advanced technologies, and convert to more effective 
technology such as a database management system. 
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VII. CONCLUSION AND RECOMMENDATION 



The ROK Army is striving to improve the efficiency and effectiveness of its 
Defense Resource Management System (DRMS). In order to achieve complete self- 
defense of ROK in a manner superior to North Korea, the allocation and expenditure 
of limited defense resources must be accomplished in a well-managed cost-effective 
manner. 

Coupled with the establishment of the Defense Budget Revolution Committee 
(DBRC) in 1983, the ROK Army has taken a series of steps to enhance the DRMS. 
The major objective of this attempt was to establish a rational cyclic process of 
planning, programming, budgeting, execution, and evaluation. This is called called 
PPBEES. The DBRC selected eight major functional areas to be addressed as the 
means for implementing the newly introduced budget system: 1) decision making 
process, 2) planning - programming process, 3) project management system, 4) 
decentralized management system, 5) analysis and evaluation system, 6) computer- 
based MIS system, 7) resource management staff function, 8) reorganization. 

So far, the ROK Army has seen a considerable improvement since the initial 
implementation of the DRMS, however it is also recognized that there are still trials 
and errors due to a lack of experience. In this thesis, we identified several limitations of 
the current DRMS: 

• Emphasis on financial data which ignores operational data 

• Unsuitable and insufficient data collection methods 

• Deficiencies in the analysis of information requirements 

• Inadequate development of data analysis and decision support models 

The data base approach is regarded as the most practical method, not only to solve the 
current problems, but also as a means to further improvement. Since the availability of 
timely and accurate data about the operations, finance, and resource allocation is the 
key to the management of an organization, the need for an effective DRMS is 
increasing. A database system, as a mechanized and controlled data pool, provides 
many advantages that are not available in the traditional file system. These advantages 
include: 1) reduced redundancy, 2) data application, 3) program-to-data independence, 
4) unpredictable query, 5) data integrity, 6) security. 
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The relational database model is discussed in this thesis because the model 
provides very powerful and flexible functions that can be easily applied in the DRMS 
because of its ability to manage complicated and multi-faceted activities. We showed a 
basic design of the relational database in a preliminary form , based on the user's 
information requirements. Since a thorough study of information requirements is 
essential for database design, we identified the information requirements for generating 
formal reports and various internal analysis. Then, we determined the input data 
formats (relations) realizing the importance of data relationships to later data 
manipulation capability. The designer of a relation should keep in mind the principles 
of independence, elimination of anomalies, and ease of use. Data values in a relation 
have relationships with other data values in different relations according to their 
unique characteristics. In order to retrieve the data stored in a database, a data 
manipulation language such as SQL is used. The user can obtain required data in a 
desired format by the simple queries. We used some mock data to demonstrate SQL 
data manipulation. 

The retrieved data from the database can satisfy the user only when they are 
processed to provide information in the useful form. As an example, consider how raw 
material is processed to become finished goods and then made available to the 
customer at a commercial value. We now must adopt the appropriate model which can 
satisfy the user's information requirements most effectively. In most cases, the applied 
model is to be selected prior to deciding the kind of data to be stored. In order to 
maximize the computer-based database system, we must develop models appropriate to 
our particular circumstances. 

The expected contributions to the resource management system from the 
relational database can be illustrated as follows: 

• Accumulation of various operational data for future use 

• Improved reliability and consistency of analytical procedures 

• Enforced standards, integrity, and security 

• Centralized control over the DRMS 

• Reduction of the personal workload through office automation 

• Easy generation of accurate and timely data 

• Improved cooperation between the functional staff departments through data 
sharing 

• Reduced conflicting requirements and redundancy of data 
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We recommend the establishment of a database system at the division level. 
Since each ROK Army division is already equipped with the computer mainframe as 
distributed throughout all the military services, this database system will enhance the 
overall military MIS system. 

In addition to the above recommendation, we propose the implementation of the 
following actions in order to establish the successful database system: 

• Expand and develop the existing coding system so each item has one code 
number 

• Establish a standard pricing system 

• Redesign Resource Transaction Slip as previously recommended 

• Develop the appropriate analysis models 

• Extend the computer system to the company level through a PC terminal 
network 

A well developed data base management system offers solutions for the 
complicated requirements of the DRMS. Considering the planned reorganization of 
the resource management staff, the introduction of data base can be the turning point 
toward the overall improvement of DRMS in the ROK Army. 
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APPENDIX A 

SUBCATEGORIES OF EACH INTERNAL DOCUMENT 



1. Unit supply Transaction & Assets 

1) SUBCATEGORIES OF INFORMATION: 

a Resource class: ( 7 classes of floating assets; cash, foods, petroleum & oil, 
ammunitions, repair parts, individual maintenance materials, and group 
maintenance materials ) 

b Beginning stock 
c Logistic Support Command 

• beginning due-in(D/I) 

• net request 

• receipt 

• ending D/I 

• return 

d Organization unit 

• beginning D/I 

• net request 

• supply 

• ending D/I 

• return 

e Ending stock 
f Changes in stock 

2) PURPOSE: Checking the supply support amount and measuring the stock. 

2. Total Unit Resources 

1) SUBCATEGORIES OF INFORMATION: 
a Unit Name 
b Cash 
c Foods 
d Petroleum & Oil 
e Ammunitions 
f Repair Parts 
g Individual Materials 
h Troop maintenance materials 
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i Total 

2) PURPOSE: Allocating resources 

3. Chances in Inventory Report 

1) SUBCATEGORIES OF INFORMATION: 
a Resource class 

b Beginning inventory 
c Receipt 
d Return 
e Availability 
f Utilization 
g Ending inventory 
h Changes in inventory 
i Request 

j Cancellation of request 

k Ending due-out (D/O) 

2) PURPOSE: Calculating the supply transactions between organizational unit 
and division. 

4. Unit Resource D/O Report 

1) SUBCATEGORIES OF INFORMATION: 
a Unit Name 

b Foods 
c Petroleum & Oil 
d Ammunitions 
e Repair parts 

f Individual maintenance materials 
g Troop maintenance materials 
h Total 

2) PURPOSE: Measuring the D / O of each unit by each resource. 

5. Unit Resource Utilization Report 

1) SUBCATEGORIES OF INFORMATION: 
a Unit Name 
b Cash 
c Foods 
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t 



2 ) 



d Petroleum & Oil 
e Ammunitions 
f Repair parts 

g Individual maintenance materials 
h Troop maintenance materials 
i Total 

PURPOSE: Comparing the resource utilization of each organizational unit. 



6. Unit Activity Expense Report 

1) SUBCATEGORIES OF INFORMATION: 
a Activity 

b Cash 
c Foods 
d Petroleum & Oil 
e Ammunitions 
f Repair parts 

g Individual maintenance materials 
h Troop maintenance materials 
i Total Percentage (%) 
j Budget 

k Expense / Budget (%) 

2) PURPOSE: Evaluating the expenses of each activity 



7, Budget Allocation and Expenditure 
1) SUBCATEGORIES OF INFORMATION: 
a Activity 
b 1/4 Quarter 

• budget 

• expenditure 

• percentage (%) 
c 2/4 Quarter 

• budget 

• expenditure 

• percentage (%) 
d 3/4 Quarter 

• budget 
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• expenditure 

• percentage (%) 
e 4/4 Quarter 

• budget 

• expenditure 

• percentage (%) 
f Total 

• budget 

• expenditure 

• percentage (%) 

2) PURPOSE: Measuring budget expenditure by each quarter and each activity. 

8. Cash Disbursement Report 

1) SUBCATEGORIES OF INFORMATION: 
a Unit name 

b Personnel expenses 
c Material expenses 
d Maintenance expenses 

2) PURPOSE: Calculating cash disbursement by each item. 

9. Cash Disbursement by Activity 

1) SUBCATEGORIES OF INFORMATION: 
a Item 

b Basic maintenance expense 
c Commanding activity expense 
d Mission completion expense 
e Fringe benefit & welfare expense 
f Capital investment 
g Supplementary mission expense 
h Total 

2) PURPOSE: Calculating cash expenditure by activity. 
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10. Equipment expense coefficient report 

1) SUBCATEGORIES OF INFORMATION: 
a Equipment 

b Operation unit 
c Amount 

d Petroleum & Oil expense 

• Fixed expense 

• variable expense 
e Maintenance expense 

• Fixed expense 

• variable expense 
F Total 

• Fixed expense 

• variable expense 

2) PURPOSE: Providing criteria For allocating and budgeting resources. 

1 1. Equipment operation by activity 

1) SUBCATEGORIES OF INFORMATION: 
a Equipment 

b Amount 

c Operating perFormance by activity 

• logistic activity 

• commander & staff activity 

• mission activity 

• welfare activity 

• total 

d Maintenance expense 

• operating expense 

• troop maintenance expense 

• Field maintenance expense 

• total 

2) PURPOSE: Evaluating the operating performance and maintenance expenses 
of each equipment. 



12. Operating Performance of Each equipment 

1) SUBCATEGORIES OF INFORMATION: 
a Equipment code 

b Cumulative operating performance 
c Operating performance by activity 

• logistic transportation 

• commanding & staffing 

• mission completion 

• welfare 

• total 

d maintenance expense 

• petroleum & oil 

• troop maintenance 

• field maintenance 

• substitution of repair parts 

• total 

2) PURPOSE: Evaluating the operating performance and maintenance costs 

of each equipment. 

13. Unit Training Cost Report 

1) SUBCATEGORIES OF INFORMATION: 
a Type of training 
b Length 
c # of personnel 
d Distance of mobilization 
e Equipment 
a vehicle 

b amounted vehicle 
c gunnery 
d total 

f Resource utilization amount 

• petroleum & oil 

• ammunitions 

• repair parts 

• cash 
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• other 

• total 



2) PURPOSE: Comparing the resource utilization of organizational unit 
in training. 

14. facility Maintenance Cost Report 

1) SUBCATEGORIES OF INFORMATION: 
a Type of facility 

b Amount 
c Size (square meter) 
d Maintenance costs 

• cash budget 

• material budget 

• total 

e Average maintenance cost 

• per amount 

• per area(size) 

2) PURPOSE: Analyzing the maintenance costs of each facility. 

15. Combat Equipment Average Life Analysis 
1) SUBCATEGORIES OF INFORMATION: 

a Combat urgent equipment 
b Amount 

c Combat urgent equipment and parts 

• stock number 

• name 

• unit 

• unit price 

d Total substitution times 

• times 

• cost 

e Average substitutation times 

• times 

• cost 

f Average life (hours) 

g Average life (operation) 
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2) PURPOSE: Forecasting the demands of combat urgent equipments and repair 
parts. 

16. Supply Support Required Time Analysis 

1) SUBCATEGORIES OF INFORMATION: 
a Resource class 

b # of transactions 
c Required Time (day) 

• 0-8 days 

• 8-15 days 

• 15-30 days 

• 30 - 60 days 

• 60 - 90 days 

• 90 - 150 days 

• over 150 days 

2) PURPOSE: Analyzing the OST of supply support command. 

17. Inventory Stockout Report 

1) SUBCATEGORIES OF INFORMATION: 
a Resource class 

b 30 days 

• item 

• money amount 
c 90 days 

• item 

• money amount 
d 180 days 

• item 

• money amount 
e Over 180 days 

• item 

• money amount 
f Total 

• item 

• money amount 

2) PURPOSE: measuring the stockout of each resource. 
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18. Combat Urgent Equipment and Repair Parts Stockout Report 

1) SUBCATEGORIES OF INFORMATION: 

a Type of materials 

b Stock number 
c Item name 
d Unit 

e Unit price Necessity amount needed in combat 
f Amount of current stock 
g Anticipated receipt amount 
h Degree of urgency 
i Days of stockout 

2) PURPOSE: Measuring the stockout of combat urgent equipments 

and repair parts. 
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APPENDIX B 
CODING SYSTEM 



1. UNIT CODE 

A. Formation : 4 digit number 

B. Description : Each unit or functional staff office has its own code and is 

responsible for the resource transaction/ expenditure. The code is assigned from the 
higher level of command through the company level around the division and identifies 
the chain of command of a unit. 

C. Structure 

(1) 1st digit: units classified into their basic mission. 

- 0: higher echelon of command or adjacent unit 

- 1: the division headquarter & headquarters 

- 2: functional staff office 

- 3: infantry unit 

- 4: artillery unit 

- 5: combat support unit 

- 6: service support unit 

(2) 2nd digit: a serial number of the command or organizational unit under the 
same mission 

- 01: army command 

- 02: corps 

- 03: logistics support command 

- 04: adjacent unit (division level) 

- 21: personnel staff office 

- 22: intelligence 

- 23: operations and training 

- 24: logistics 

- 25: planning 

- 26: civilian 

(3) 3rd digit: the first subordiate unit of the organizational unit (battalion level) 

(4) 4th digit: the second subordiate unit of the organizational unit (company leval) 
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EX) 0300: logistics support command 
3100: 1st infantry regiment 
3110: 1st infantry regiment 1st battlion 



2. TIME CODE 

A. Formation : 6 digit number 

B. Description : the date or time period of resource activity 

C. Structure 

- 1st 2 digit: year 

- 2nd 2 digit: month 

- 3rd 2 digit: day 

EX) 871011: Oct 11, 1987 

3. RESOURCE CODE 

A. Formation : 4 digit number 

B. Description: All the resources (except cash) following through the division are 
classified into their own codes one by one, according to their charcteristics. 



C. Structure 

(1) 1st digit: function class 

- 1: firing E. 

- 3: maneuvering E. 

- 5: ammunitions 

- 7: material I 

- 9: material II 



2: special weapon 

- 4: airplane 

- 6: general equipment 

- 8: medical E. 

- 0: ship 



(2) 2nd digit : resource class 

- 1: cash 

- 2: food 

- 3: petroleum & oil 

- 4: repair part 

- 5: ammunitions 

- 6: individual maintenance material 

- 7: troop maintenance material 



(3) 3,4th digit: subclassification of each resource group(class) 



EX) 7301: gasoline 
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4. EQUIPMENT 

A. Formation'. 8 digit number 

B. Description'. The code ranges the whole equipments of the division and the 
individual equipment has its own inherent code number. Equipments are differentiated 
from the other materials bacause they are not consumable and operated semi- 
permanently. 

C. Structure 

- 1st digit: function class 

- 2nd digit: sub-functional classification 

- 3rd, 4th digit: applicable equipment 

- 5, 6th digit: model number (last 2 digit of the whole number) 

- 7, 8th digit: equipment serial number of the unit 

EX) 1-3-01-05-01: firing equipment, gunnery, 105mm howitzer, model 5, #2 
3-1-01-20-01: maneuvering, general vehicle, 1/4 ton, model 20, #1 
3-2-02-02-03: maneuvering, combat vehicle, M46 Tank, model 2, #3 

5. FACILITY CODE 

A. Formation: 3 digit number 

B. Description: Facility code includes real property (land, building etc.) and the other 
fixed structures in the unit. 

C. Structure 

(1) 1st digit: facility class (according to the purpose) 

- 1: basic maintenance - 2: training and educational 

- 3: tactical - 4: engineering works 

- 5: welfare - 6: service support 

- 7: storage (warehouse, tank) 

(2) 2, 3rd digit: subclassification of the facility 

6. PURPOSE CODE 

A. Formation: 2 digit number 

B. Description: The code indicates the purpose for which resources are expended, 
c. Structure 
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(1) 1st digit number 

- 1: basic mission activity (administration & supply) 

- 2: command and staff activity 

- 3: major mission performance (training, operations etc.) 

- 4: welfare (medical ....) 

- 5: investment (acquisition of equipment, facility and weight material) 

- 6: others 

(2) 2nd digit: subclassification of each mission activity 
EX) 31: training; 20: commanding & staff activity 



7. BUDGET CODE 

A. Formation : 10 digit number 

B. Description : Classification for the accounting purpose; The current system of 
'ROK defense budget item code system' has alreay been developed. 

C. Structure 

- 1st 2 digit: budget chapter(budget class group) 

- 2nd 2 digit: budget section (sub-class) 

- 3rd 2 digit: budget item (subsub-class) 

- 4th 2 digit: budget sub-item 

- 5th 2 digit: the lowest budget item 

8. TRANSACTION CODE 

A. Formation : 5 digit number 

B. Description : The flow of resources in and out of the division; Transactions are 
identified based on the four factors: item, flow line, objective, and frequency. 

C. Structure 

(1) 1st digit number: Types of transaction 

- 1: supply 

- 2: return 

(2) 2nd digit: resource class (1 throug 7) 

(3) 3rd digit: transaction line 

- 1: army command — > division 

- 2: corps — > division 
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- 3: logistics support command — > division 

- 4: division — > subordinate organizational unit 

- 5: organizational unit — > division 

- 6: division — > logistics support command 

(4) 4, 5th digit: the serial number of transaction over the same item 

9. REQUEST CODE 

A. Formation : 6 digit number 

B. Description : Every occurance of request/cancel for supplies is assigned the time* 
sequential number. 

C. Structure 

(1) 1st digit: Request type identification 

- 1: request 

- 0: request cancellation 

(2) 2, 3, 4th digit: Resource class (1 through 7) and sub-class 

(3) 5, 6th digit: Request serial number annually given to each resource class 
(regardless of request or cancellation) 

EX) 130105: the 5th request for petroleum (gasoline); 030105: cancellation of 5th 
request 
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APPENDIX C 

APL PROGRAM FOR THE OPTIMAL ALLOCATION OF REPAIR 

PARTS 



C13 
[ 2 : 
[33 
[43 
[53 
Z6 3 
Z71 
- 8 - 
-9- 
- 10 - 
- 11 - 
- 12 - 
Cl 3 ] 
[1 43 
[153 
[163 
[173 
[183 
[193 

[203 

C21] 

[223 

[233 

C243 

[253 

[263 



VCOMPZQIV 

V ID COMP DATES ; FAIL ; REPAIR 

R OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 
0 0 O 

0 o 
ft o 

00 o 

0 O PURPOSE : WRITING A SIMPLE AP£ FUNCTION TEAT USES INPUT FROM o 

o o DIFFERENT DATA VECTORS , PERFORMS SOME SIMPLE CALCU- 0 

o - L AT IONS ON TEE INPUT DATA, AND OUTPUTS TEE RESULTS 

o - IN A READABLE MANNER. 



a 


- 






- 


p 


- 


KEY VARIABLE 


- 


p 


- 


ID 


ITEM IDENTIFICATION DATA 


<Z» 


p 


0 


DATES 


FAILURE AND REPAIR DATE OF COMPONENTS 


O 


p 


0 


FFD 


FIRST FAILURE DATE OF COMPONENTS 


0 


p 


0 


LFD 


LAST FAILURE DATE OF COMPONENTS 


0 


p 


0 


AP 


ANALYSIS PERIOD 


0 


p 


0 


ADF 


AVERAGE DAILY FAILURE 


0 


p 


0 


TAT 


TURN AROUND TIME 


0 


p 


0 


RBAR 


AVERAGE NUMBER IN REPAIR 


0 



00 o 

0 00000000000000000000000000000000000000000000000000000000000000000000 

N+(pDATES)*2 
FAIL+N+DATES 
REPAIR+N+ DATES 
ITEM ID 

FAIL COMPUTE REPAIR 
V 



V COMPUTE [03V 

V FAIL COMPUTE REPAIR ; FFD ;LFD;AP;TF; ADF ; TAT ; MINT AT ; MAXTAT ; A VET AT ; RBAR 
[13 r * 

[23 0 CALCULATE TEE STATISTICS OF INPUT DATA 

[33 * 1 

[43 FFD+l/FAIL 

[53 LFD+Z /FAIL 

[63 AP+UFD-FFD)* 1 

[73 TF^pFAIL 

[83 ADF+TF*AP 

[93 » » 

[103 B COMPUTE TURN AROUND TIME , MINIMUM, MAXIMUM, AND AVERAGE OF TAT 
[113 • « 

[123 TAT+ (REPAIR- FAID+1 
[133 MINTAT-*- L /TAT 
[143 MAXTAT+Z /TAT 
[153 A VET AT* ( + /TAT ) *TF 
[163 * • 
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o o 



[17] 

[18] 

[19] 

[ 20 ] 
[ 21 ] 
[ 22 ] 

[23] 

[24] 

[25] 

[26] 

[27] 

[28] 

[29] 

[30] 

[31] 

[32] 

[33] 

[34] 

[35] 

[36] 

[37] 

[38] 

[39] 
> 0 ] 
[41] 



A COMPUTE VIE AS Mill NUMBER IS REPAIR 

t t 



RBAR+ADFxAVETAT 

i 



******* DATA ANALYSIS ******* ' 



FIRST FAILURE DATE 
LAST FAILURE DATE 
ANALYSIS PERIOD 

t 

TOTAL FAILURE 
A VERA GE MIL! FAI LURES 

i 

T URN MQDND TIMS’ 

r 

MINIMUM 

MAXIMUM 

AVERAGE 



' , ( 9FFD 
1 , ( 9LFD ) 

• . ( vTF ) . ' 

• , ( vADF ) , 1 



JULIAN DATES’ 

DAYS’ 

UNITS' 

UNITS / DAY ' 



' , ( 9MINTAT ) , ' 
' , ( 9MAXTAT ) , ' 
• , (vAVETAT), ’ 

’ , (9RBAR),' 



DAY’ 

DAYS' 

DAYS’ 



MEAN DAILY NUMBER IN REPAIR 

i 

i 

i 

******* RESULTS QF ANALYSIS ******* ' 

i 



UNITS ' 



[42] 
[43 ] 

[ 44 ] 

[45] 

[46] 

[47] 

[48] 

[ 49 ] 

[50] 

[51] 

[52] 

[53] 



' EQISSQN DISTRIUTION TABLE’ 

i i 

' N P{X<,N) PROTECTION LEVEL’ 

( 3 , p K ) pK , CDF , 1 0 0 x C0F«-+\( * -EBAR) x TrBAR*K ) + I R+0 , i T 4 xRBAR 

i i 

' * N - TRE NUMBER OF COMPONENTS WRICR SHOULD BE STOCKED TO PROVIDE’ 
' PROTECTION FROM STOCKOUT AT THE PROTECTOION LEVEL.’ 

i i 

' * P(XZN) - PROBABILITY THAT AT MOST N COMPONENTS ARE NEEDED.’ 

i i 

1 * PROTECTION LEVEL - THE LEVEL AT WHICH THEY WILL PROVIDE ' 

' PROTECTION FROM STOCKOUT IF N COMPONENTS ARE STOCKED , ' 

V 



1] 

2 ] 

3] 

4] 

5] 

6 ] 

7] 

8 ] 



VITEMZniV 

V ITEM ID ; NSN ; NAME ; APPLI ; PRICE 

i t 



* **************** ITEM IDENTIFICATION ***************** * 

i i 



'NATIONAL STOCK NUMBER 
' COMPONENT NAME 
'APPLICATION 
'PRICE OF COMPONENT 
V 



' ,9NSN+17*ID 
’ .vNAME+m + lQ+ID 
' t 9APPLI+8+*2+ID 
’ , ( 9PRICE+7 ♦ 5 0 + ID ) , ' DOLLARS ' 
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7 DESCRIBE 

Cl] * THIS WORKSPACE CONTAINS THREE FUNCTIONS ( 2 GENERIC FUNCTIONS ) AND* 

[2] 'TWO VARIABLES , WHICH CAN COMPUTE THE STATISTICS OF DATA.' 

[3] ' ' 

[4] « FUNCTIONS ARE ' 

[5] ' COMP * TYPE COMPHOW TO SEE BOW TO RUN. ' 

[6] • ITEM «■ GENERIC FUNCTION TO PRINT ITEM IDENTIFICATION . ' 

[7] « COMPUTE * CALCULATE THE STATISTICS OF DATA.' 

[ 8 ] • ' 

C9] 'AND IT HAS DATA OF ITEM ID. , FAILURE AND REPAIR DATES OF TOW' 

CIO] ' COMPONENTS .' 

7 

VC0MPB0WZQ1V 

7 COMPHOW 

Cl] 'THE COMPHOW IS DYADIC FUNCTION THAT REQUIRES TWO INPUT MATRICES THEN « 

C2] ' COMPUTE THE STATISTICS OF THEM AND PROVIDE A TABLE THAT SHOWS THE NU' 

C3] 'MBER OF COMPONENTS AND CDF OF THE POISSON DISTRIBUTION P(X£).» 

C4] » ' 

C 5 1 'THE SYNTAX FOR CALLING THE FUNCTION IS :» 

C6] ' ID COMP DATES' 

C7] 'WHERE ID IS A ITEM IDENTIFICATION' 

C8] ' DATES IS A ITEM FAILURE DATE AND ITEM REPAIR DATE WHICH JOINED' 

C9] * WITH ' 

CIO] 

7 
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